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ABSTRACT 


Management information is of critical importance in modern 
decision makıng,. the role of the computer in this process 
HEN diussuAHdawES cnesting Challenging goals for data 
meecessime Specialises and functional area specialists alike. 
A totally integrated computer based management information 
System (MIS) requires long term planning and design efforts 
coupled with detailed analysis of information system require- 
ments. The MIS development generally follows a master plan; 
this master plan contains three major phases: MIS Analysis, 
Mises Ten. tandas Implementation. The different phases 
through which the master plan evolves are known as the system 
development process, This thesis describes the development 


of the master plan. 
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I. INTRODUCTION 


cmd le 195015 the first computer was installed for 
a business application: processing of payroll. Twenty years 
later there were over 100,000 computers in the United States 
and a like number in the rest of the world. Payroll proces- 
Sing by computer, which was a revolutionary idea in 1954, is 
now considered a rather routine application. Today the fron- 
tiers in information processing are systems which also provide 
information resources in support of managerial and decision- 
making functions. Such a system is called a Management Infor- 
mation System or, more commonly, MIS. 

The key to managerial success in the present automated 
environment lies in being able to collect, quantify, retrieve 
and effectively use the information available in the decision 


making process. 


a, OBJEGTIVES 

This discourse is an attempt at a sketch of that body of 
knowledge known as system analysis. The kind of system anal- 
ysis that is examined here is that which deals with informa- 
tion systems. 

A discussion of the stages of building a management infor- 
mation system (referred to hereafter as MIS) should provide a 
reference or guide for those who are presently involved in 


future information system development. 





A step-by-step discussion of the System Life Cycle will 
be presented and an attempt will be made to utilize it in 
the development of a MIS. 

Systems Integration will be the point which will be 


stressed throughout this discussion. 


Eee SER! LIFE CYCLE 
1. Definition of Systems 
A system [1] can be defined as a network of inter- 
related procedures that are joined together to perform some 
ewe hey unction Of Operation. It is, in effect, all the 
ingredients which make up the whole. And a procedure is a 


precise series of step-by-step instructions that explain: 


- What is to be done. 


Who will do it. 


When will it be done. 


- How will it be done. 


Ce on or Systems Analysis 
System Analysis [2] is the process of studying the 
network of interactions within an organization and assisting 
in the development of new and improved methods for performing 


necessary work. 


rd 


Ta e Development Process 


The System Development Process is a guideline for the 
development of computerized systems. It is a comprehensive 
process ibecinnins with the definition of a problem and includ- 


ing the design and implementation of a new system which will 





pocceumuesbsobDuyem. It discusses the complete life cycle of 
den, srommıtsemsmtial conception to its ultimate disposal. 
(See Figure 1.1.) Figure 1.1 has been derived from references 
EN and [4]. 
The System Life Cycle consists of the following acti- 
vities: 
a. Conception 
System Conception is the identification of a need 
which, it is suspected, can be satisfied by the development 
of a new system. At this stage the need for a new informa- 
tion system is first recognized. 
b. Preliminary Analysis 
The Preliminary Analysis is the investigation into 
HUN GcwbIPMty. desirability, and practicability of using 
automated data processing techniques to solve information 
needs. 
C. Preliminary Design 
The Preliminary Design is the stage in which the 
project team evaluates alternate design approaches, selects 
preferred design approach, writes preliminary design specifi- 
cations and writes the test specification. The basic system 
is established at this stage. 
d. Detailed Design 
The Detailed Design is the stage where the basic 
system designed is expanded and refined to produce detailed 
Specifications for all program modules, manual procedures, 


musernktormation files. 
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e, Configuring and Selecting the Computer Equipment 
The previous stages were the basis for setting 
up exactly which applications are to run on the system. 
At this stage, the configuration of the computer 
Svstem (Hardware/Software) is established and the selection 
and evaluation of vendors are accomplished. 
f. System Programming 
The logic for the computer's programs is developed 
at this stage, following the system specifications accepted 
by the user. Once the logic has been set up the programmers 
begin coding and testing each program in the system. 
g. System Documentation 
system Documentation is the collection and pres- 
entation of the information concerning the system. Informa- 
tion is recorded starting from the conception of the system 
and ending with the cessation of it. 
h. System Testing 
System Testing is the process of trying to demon- 
strate that the system performs its intended function. 
i. System Implementation 
System Implementation consists of the tasks 
involved in implementing the system in the operating environ- 
ment. 
j. System Operation 
Steiner atron Ls the production phase. Res- 


ponsibility for the system is now shifted to the operations 
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group. However, the designers and programmers can contribute 
comal ne the transition easy. 
k. System Maintenance and Follow-up 
Once the system has been made operational, it is 
important to have a continuing support service to maintain 
the hardware and software. 
I System Cessation 
System Cessation is the end of the System Life 
Cycle. The system approach assumes that all systems have a 
finite life and, theretore, will eventually expire. 
The application of the System Life Cycle to the 


development of a MIS will be discussed later. 
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II. MANAGEMENT INFORMATION SYSTEMS 


A. DEFINITION OF DATA 

DAS ateo acts which could represent quantities, 
Tons, chamsessetc., but which are in unusable form for 
tie recipient unless they are submitted to some sort of 


processing. 


B. DEFINITION OF INFORMATION 
Information [5] is data that has been processed into a 
form that is meaningful to the recipient and is of real or 


perceived value in current or perspective decisions. 


C. PRODUCING INFORMATION FROM DATA 

It has been established that data need to be processed 
order. to Eranstorm it in meaningful information for the 
recipient. This transformation can be viewed from two dif- 
ferent viewpoints. First a logical viewpoint, the operations 
performed on data and second, a technical viewpoint, the 
methods by wnich data operations are performed. 

l. Data Operations 

In order to make the data useful to the recipient, 

some combinations of operations need to be performed on it. 
The following are the set of operations, as described by 


Bumch [6]: 


I5 





a. Gapturing 
Operation of recording the data from an event 
amo cuUnrentese in some form sueh as sales slips, personnel 
fomms, purchase orders and so forth. 
b. Verifying 
E Operation for checking that data have been 
recorded correctly. 
ee». Classa ty ine 
Operation that places data elements into specific 
categories which provide meaning for the user. 
d. Sertime 
Operation that arranges data elements in a 
Snes ed or predetermined sequence. 
e. Summarizing 
Summarizing’ can be done in two ways: First, it 
accumulates data in the mathematical sense, as when a balance 
Sheet is prepared. Second, it reduces data in the logical 
sense, as when the personnel manager wants a list of names 
of only the employees who are assigned to a given department. 
LC Xoonidcubdting 
Operation that deals with the arithmetic and/or 
logical manipulation of data. 
DESEO TUNE 
Operation that places data onto some storage 
media such as paper, microfilm, and magnetizable devices, 


where it can be kept for access and retrieval when needed. 
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h. Retrieving 
This operation entails searching out and gaining 
access to specific data elements from the medium where they 
are stored. 
1.  Reproducing 
This operation duplicates data from one medium 
to another, or into another position in the same medium. 
me anple of this operation is the duplication of files 
for security reasons. 
j. Disseminating/Communicating 
This operation transfers data from one place to 
another. The ultimate aim of all data processing is to 
disseminate information to the users who need it. 
2. Data Processing Methods 
In order to carry out the data operations previously 
described, four broad categories, based on the level of 
wc ommation used for processing the data, can be defined: 
a. Manual Method 
All of the data operations are performed by hand 
with the aid of basic devices such as pencil, paper, slide 
Imc and so forth. 
b. Electromechanical Method 
EMEN I3 mbIOGSTS Of man and machine. 
Example of this method includes an operator working at a 


cash register. 


LS 





c. Punched Card Equipment Method 
It entails the use of all devices used in what 
is sometimes referred to as a unit record system. Data 
concerning a person, object, or event are normally recorded 
(punched) in a card, 
Iron Computer 
All of the data operations, are performed by an 
electronic computer. The computer provides significantly 
greater data processing capabilities that the other three 
methods. 
A table showing the relationship between the 
data operation and the data processing methods can be seen 


EM cure 2.1. 


D. VALUE OF INFORMATION 

Information is a valuable resource in any organization. 
Nuhout comal information most organizations could not 
survive. 

Decisions can be made under certainty, risk and uncer- 
tainty. Decision under certainty assumes perfect information 
is available concerning outcomes; risk assumes information 
is available about the probability of each outcome but no 
knowledge of possible outcomes; and uncertainty assumes a 
knowledge of possible outcomes but no information about pro- 
busty of outcome [5]. 

Information can be studied in terms of its cost and 


value. While the cost of providing information is tangible 
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EudEtaertbv measurable, its value is conceptual in nature 
and has less tangible characteristics. 
OS o cor mat ion 
Information is not free. The preparation of infor- 
mation for decision making costs money. The following are 
some of the elements that need to be considered when esti- 
mating the cost of producing information, for a computer- 


based MIS: 


Cost of the computer system. 


Cost of developing the system. 


Cost for on-site preparation. 


Cost of conversion from the present system to a 
computer-based system. 
- Cost of operation. 
2. Value of Information 
BlcevduMSoGMO5SMAtlon is based on its attributes, 
and because of the conceptual nature of information some of 
those attributes are difficult to measure, The list of 
these attributes, as given by Burch [6] follow: 
ae ceSSi bi ley 
This refers to the ease and speed with which an 
smtormatjon otput- can be obtained. 
b. Comprehensiveness 
This refers to the completeness of the information 
Comrvent, Slims attribute is quite intangible and consequently, 


PES dif fic to quantify. 


IS 





E 
This attribute pertains to the degree of freedom 
ON error of the information output. 
d. Appropriateness 
This attribute refers to how well the information 
output relates to the user's request. 
e. Timeliness 
The user must receive the information, within the 
time allowed, for the decision or action to which it is ap- 
pulred. 
fee Clarity 
This attribute refers to the degree an informa- 
p nEOUBEDUL is free from ambiguous terms, 
sa eee oto aed Ie Gy. 
This attribute pertains to the adaptability of 
ang Hneermatron output not only to more than one decision, 
but to more than one decision maker. 
ewe er li tap 111 ty 
This attribute refers to the ability of several 
users examining an information output and arriving at the 
Same conclusion. 
1. Freedom from Bias 
This attribute pertains to the absence of intent 
| cM or modify information in order to produce a pre- 
conceived conclusion. 
j. Quantifiable 
This attribute refers to the nature of information 


produced from a formal information system. 
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E. SEFINITION OF A MIS 

Actually there is not universal agreement among managers 
and computers scientists, about what is a MIS. Some of 
the definitions that were found follow: 

"AneMIS System, fundamentally, is a financial control 

system which is the principal basis of a good planning 

system 177." 

"A MIS is a system of people, equipment, procedures, 

documents, and communications that collects, validates, 

operates on, transforms, stores, retrieves, and pre- 
sents data for use in planning, budgeting, accounting, 
controlling, and other management processes for various 

management purposes [8]." 

"A management information system may be defined as an 

organized method of providing management with informa- 

tion needed for decisions, when it is needed and in a 

form which aids understanding and stimulates action [9]." 

"A MIS is an integrated, man/machine system for provid- 

ing information to support the operations, management, 

and decision making functions in an organization. The 

System utilizes computer hardware and software, manual 

procedures, management and decision models, and a data- 

pase 15]." 

It can be said that each manager or author has its own 
definition about a MIS. Definitions abound but there is no 
eeneensus about what really constitutes a MIS. Trying to 
look for a definition or trying to essay a new one, would 
@Gemeribute to the confusion that already exists; for this 


reason no attempt was made to define a MIS. 


F. TYPES OF INFORMATION SYSTEMS 

There is no specific system envisioned when the general 
term of MIS is mentioned. Today many people have their own 
definitions. Following are brief descriptions of four basic 


types, as seen by Cicio [10]: 
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1.  Formal/Automated 
This type of information system is always the most 
sophisticated, where the machine is more the worker and the 
man more the designer, director, observer, or user. Elec- 
tronic computers with all of the associated hardware to 
complement and connect them are involved in a full blown 
automatic data processing system. 
2.  Formal/Non-automated 
This system includes all those conventions, proce- 
es. media, that are formally prescribed, legally required, 
EN habit adhered to; but which are implemented either 


manually or with minor equipment. The predominant effort is 


clerical. 
3. Informal/Formal 
This system could well be a more powerful informa- 
tional system in the key management sphere than any other 
Maot any part of the entire MIS. This is the product 
of organized advisory staff work; the formal staff meeting 
where problems are discussed; and the work of formally char- 
tered groups such as a board of directors. 
T usommai/tntormal 
A system of this sort can be information passed at 
EE ccs pare, a network of personal letters, the grape- 
wee or any other system of information exchange. This is 
included because to some extent it does carry information 


and influences management decisions. 
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LL SDBHNSPURE OF A MIS 
Düring the past several years, the structure of a MIS 
has been related to the pyramidal form of the organization. 
Figure 2.2 shows this structure. This figure has been 
adapted from reference [11]. 
This basic structural concept reflects two ways of the 
meio semucture ; 
1. On the Basis of Management Activity 
This concept deals with the three most widely used 
levels of management planning and controlling activities: 
Strategic, tactical and operational. 
Zee OM the Basis of Organizational Function 
This concept deals with the functions performed in 
an organization. Of course this approach will depend on 
meemparcicular organization under study. 
For purposes of illustration the following functions 
are listed for a business organization: 
- Marketing 
- Production 
- Logistics 
- Personnel 
- Finance 
- Research and Development 
- Information Processing 
Whereas the operational function view of a MIS is to 
group all activities and information processing in an organi- 


zation by function, the management activity approach is to 
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group activities and information system support by level of 


management. 


H. THE DATA MANIPULATION FUNCTION IN A MIS 

Data is the heart of a MIS, its establishment is essen- 
pon the development of any sophisticated information 
system. Data has value to the extent that it can be retrieved, 
processed, and presented to the person needing it within the 
time allowed for the decision or action to which it applies, 
therefore, data that cannot be located or processed on time 
have no value. 

Petilouwctyisions the availability of a fairly compre- 
hensive set of stored data in order to provide information to 
support operations, management, and decision making in an 
Eusunwzatron. The system must then be able to selectively 
retrieve various combinations of stored data on demand of 
the manager. The manager's requirements for information are 
rarely fixed and vary with the dynamic nature of the organi- 
Fac LOM. 

File processing systems and data base processing systems 
donte two basic approaches for data organization in a MIS. 

ISE OE ess Approach 

File-processing systems are predecessors of data 
base processing systems. In this approach each application 
is processed separately by using separate files. Each data 
file is designed with its own storage area and also designed 


DN se for the needs of the users requesting the 
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application. Typically, the computerized files maintained 
by most organizations exhibit the following deficiencies [12]: 
S." kacksof Integration 
Data is conveniently organized into records and 
bes FOr Maintenance and processing, but such organization 
frequently fails to give recognition to its mutual relation- 
ship. Data redundancy is one of the problems due to lack of 
iieesnatlon. 
b. Lack of Program Independence 
System analysts and programmers have virtually 
complete responsibility for designing and implementing an 
application. This includes, in addition to the logical 
design of the application, the design of all the files and 
records associated with it and the preparation of programs 
LX Imput, output, and updating of information. The 
tendency has been to design those programs in order to handle 
the Specific data contained in the application file. The 
practical effect of this is that any change in data organi- 
zation will require a change somewhere - usually in several 
places in one or more programs. 
C U ability for On line Usage 
The approach to file organization in the past 
has been to structure sequential files consisting of physi- 
Seely contiguous records and sequenced according to a key. 
There is a serious problem in adapting existing files to 
on-line usage. The time required to search a sequential file 


es ip roportionately with the size ot that file, so that 
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for an application of any magnitude, it is impossible to 
provide an immediate response to a request for information. 
A schematic diagram, showing the file processing approach 
ExuSbe seen in Figure 2.5. This figure has been adapted 
from reference [13]. 

2. Database Approach 

The term database is not a new one; it became 
eurent in the lates 1960s. Prior to that time, the terms 
files of data and data sets were used. Many organizations 
weed the new term to name their files of data but no 
changes were made in order to improve the previous estab- 
ined deficiencies in file processing. 

Martin [14] defines a database as follows: 

"A database may be defined as a collection of inter- 
related data stored together without harmful or 
unnecessary redundancy to serve one or more applica- 
tions in an optimal fashion; the data are stored so 
that they are independent of programs which use the 
data; a common and controlled approach is use in 
adding new data and in modifying and retrieving 
existing data within the database. One system is 

ede co Contain a collection of data bases if they are 
ewi rely separate in structure." 

The use of a database system in a MIS will allow a 
eona zed control of the data within the organization, 
data redundancy reduction, minimization of inconsistencies 
EDEN tored data, utilization of data for one or more appli- 
etone and a better logical data organization for both 
Mne n processing and on-line applications. 

IN dtuonetosdata organization, Some other basic 


concepts need to be implemented in order to make the database 


operational. 
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Data organization alone is not enough for establish- 
ing a database system. It is necessary to consider the 
software which performs the functions of creating and 
updating files, retrieving data, and generating reports, 
which is called the database management system. It is also 
Ncessary to consider the activity of data control, which 
is a human function performed for the Data Base Administrator 
ey: It is important to point out that the introduction 
of the DBA function could lead to an organizational change. 
Problems could arise in the organization relative to the 
management level where the DBA must be placed. If this 
function has not been established in the organization, prime 
consideration must be given to this matter if the database 
system approach is going to be used in the MIS development. 
Figure 2.4 shows a simple diagram of the database approach. 


Figure 2.4 has been adapted from reference [13]. 


ms OPERATING MODE CLASSIFICATIONS 

Input, processing, and output are common to all computer 
Posed WIS. Timing of these actions defines the operating 
modes of the system [15]. Basically two modes of operation 
Will be considered; batch processing systems and real-time 
processing systems. 

1. Batch Processing Mode 

In this mode of operation, the data that 1s input to 

the system is held for later processing rather than being 


M o essed as it becomes available; however, some kinds of 
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outputs are always produced. This happens automatically and 
usually at regular time intervals, depending on the particu- 
lar application being processed. 
2. Real-Time Processing Mode 

In these systems, fast response and fast reaction of 
the data processing system is the chief consideration. 
Usuallv this reaction is measured in seconds, and it is the 
elapsed time between the time when an inquiry is made and 
the time in which a response is obtained. Normally these 
systems are expensive. Additional hardware, software, and 
application programming cost are associated with fast res- 
ponse. Of course in these systems data is processed as 


soon as it becomes available to the data processing system. 


51 





ITEMS TEMADE VELOPMENT PROCESS 


It was established that the system development process 
EN ucurcelrne-used tor controlling the analysis, design 
and implementation of information systems within an organiza- 
tion. This guideline has been set up around the System Life 
NM co brrefly explained in the introduction of this study. 

In this section a thorough discussion of the system 
Irre cycle is presented with emphasis in its application 
to the MIS development process. 

Bee seoing turther in this study, a brref discussion 
will be presented about some topics, which are of primary 
importance for the success of the information system. The 
points that will be considered are the following: management 
involvement, and the steering committee. 

In order to be successful in the study and implementation 
of a MIS, both, support and participation of top management 
are required. Top management must support the system effort 
by itself, and demand support from line management and opera- 
tions management if necessary. In addition, it is essential 
that management at all levels, participate in the different 
stages or the system development process. 

Information analysts and managers are responsible for 
problems that arise when this lack of support exists. On the 


one hand, management is sometimes hesitant to face the system 


52 





a wetopment eftort because of its lack of knowledge of com- 
puters and information systems; on the other, information 
analysts fail, when they do not define to the management its 
eeope Of participation, i.e., what information analysts 

will expect from management at the different stages of dev- 
eliepment. 

Peitsitime OL the duties and responsibilities of managers 
and the system analysts for the various stages of MIS develop- 
ment will be given, when appropriate throughout this discus- 
Sion, as a guide for bridging the communication gap between 
the system analyst and the manager. 

The development of a MIS may lead to organizational 
problems. Some typical problems. are Control of expenses, 

Po rcummlaclon Of OG10rities and interdepartmental conflicts. 
The establishment of a steering committee has been considered 
one of the best ways for dealing with these problems. 

The steering committee is responsible for overall control 
metho continuing operation of the information system func- 
Peon ne Composition ot this committee should be based on 
the structure of a MIS, as it was explained in the previous 
Ever For Gach function performed within the organization, 
there is a top manager associated with 1t. These managers 
should be the members of the committee, and the information 
processing manager should act as the secretary. The chairman 
of the committee should be the president of the organization, 


or the executive at the highest level. 
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Functions of the permanent steering committee include 
tws following [16]: 

- It determines systems that will be automated. 

- It establishes and continually reviews system develop- 
ment priorities. 

- It reviews and approves data processing plans. 

- It reviews and approves data processing equipment 
acquisition. 


- It reviews project status. 


- It decides, when necessary, if projects should be 
continued or abandoned. 

meri res modes TeSOouLrces allocation policies. 

ee eeolvyersterriforial and political’ conflicts within 
the organization which arise due to the development of the 
new systems. 


- It continuously reviews MIS development progress. 


Pee tibo ANALYSIS 

The information system analysis addresses two main points: 
Conception and Preliminary Analysis. In the traditional 
system study, conception has been associated with the identi- 
waon of a need which, supposedly, can be satisfied with 
the development of a system. This need can exist at any 


Sua ational level. Conception in the non-traditional 


study is explained in the MIS conceptual phase. The prelimi- 
nary analysis is usually the first step taken toward the 


Sommeton of the problem. Am introductory study of the need, 
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and the practicality of using improved data processing 

EIunggues to satisfy it, are established during this phase. 

A discussion of these concepts in developing an MIS follows. 
lI. MES Conception 

The first important decision that the organization 
needs to make is whether the use of a computer will support 
and improve the decision-making process of the organization. 
Some of the factors which would justify a computer are: 

- The need for handling large volumes of data more 
efficiently than with the system presently used. 

- The need to perform complex computational problems, 
which cannot be handled efficiently by a manual. 

- The need to perform repetitive tasks quickly, 
EIJCJently, and with accuracy. 

- How the Costs of manual systems, operating with 
large volumes of data and performing complex computations, 
Gempared with the costs of computerized systems. 

- How the decision-making process can be improved 
through the use of computerized systems. 

- How the strategic plans of the firm are affected 
mE npardsson with its computer-using competitors. 

With this approach top management can determine 
aher to proceed with a detailed study. If a study is 
approved, the following steps will lead to the conception of 
anu MIS. 

- The creation of the steering committee and the 


establishment of the development team (see Appendix A). 
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- The steering committee will conduct a thorough 
dmy of the organization as it exists, and its history. 
This study will identify growth areas and pinpoint problem 
areas. Thus the need for organizational changes can be 
determined. A study of the goals of the organization will 
be conducted in conjunction with the functions it performs. 
The results to be obtained from this study can be summarized 
as follows: A clear definition of the objectives of the 
EDOoNM'Zdtion, a sharp definition of the functions performed, 
and the relationship between these functions. These func- 
tions (Finance, Personnel, Production, and the like) are the 
Bass for the MIS. 

All the necessary organizational changes are 
E wed out during this phase. Placement of the Data Pro- 
cessing Service and the implementation of the Data Base 
Pamimistrator function are also considered. 

- The next step is to identify within each function 
those subsystems that can potentially be implemented on the 
computer. This is very rough approximation that will be 
improved later during the Preiminary Analysis Phase. Now 
the MIS has been conceived; a block diagram of its initial 
ze can be seen in Figure 5.1. 

Eisure 3.1 (a) shows the structure of a MIS according 
to the functions performed by the organization. Figure 3.1 
(b) shows the subsystems division of each major system. 

This approach of conceiving the MIS may have many 
detractors within the organization. Basically the arguments 


against this approach can be summarized as follows: 
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Sa timevconsuming eftort. 

odo Peiecivere,= tor some period orf time, top 
management from its daily activities. 

- The need for computerized systems is imposed on 
users who may question the need. As a result, a resistance 
to change may be encountered at different levels. 

However, advantages can also be expected from this 
approach: 

- Top management is a member of the steering commit- 
tee; therefore their participation is assured at the earliest 
stages of the system development process. 

- The participation of top management will encourage 
@eeperation of their subordinates. 

= This approach will provide a better planning for 
the system development effort. 

ome besinning, the potential use of the com- 


mer, ser different decision levels, can be visualized. 


System integration is more easily obtained. 

- System modularity is also more easily obtained. 

2. Preliminary Analysis 

The Preliminary Analysis is intended to accomplish 
eo e lowing: Prepare the Preliminary MIS development plan, 
identify user requirements, learn the present methods of 
handling information, identify problem areas, propose a set 
oae solutions, conduct the feasibility study, prepare the im- 


plementation plan, and redefine MIS structure. 


38 





a. Establishment of Priorities 

The steering committee will assign to each 
EN stent that forms the MIS a priority for its study or analysis. 
These priorities should be given according to the importance 
poa system to the organization. Also, under the above con- 
Sept” all the subsystems that are integrated into each system 
SUN d be arranged by their priorities. The organization now 
has a first approach to the MIS development plan where sys- 
tems and subsystems are organized in the way in which they 
must be analyzed, designed, and implemented. 

b. Study of the Present Systems 

The system development team will have the res- 
e ibility of conducting this study. Although there are 
some techniques that can be used for carrying out this 
amadysis, the bottom-up approach (i.e., studying the actual 
EXBEUS starting at the operational level and going up to 
the strategic level) has been selected for the following 
reasons: 

- Operational systems which are implemented can 
produce immediate benefits to the organization. 

- Operational systems are easier to study than 
ween tical and strategic systems. 

- The system development team will accumulate 
experience, improve its skill, and will get a better under- 
standing of the system under study as it progresses up to 


the highest levels of the system. The system development 
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team will acquire a great deal of knowledge that will be 
useful in discussions with upper management. 

za Most or the internar wmformation that will 
flow through the MIS is generated at the operational level. 

In order to make the study of the present sys- 
tems easier the system is broken down into smaller struc- 
tures called subsystems. Each one of these subsystems is 
Studied by a system project team. This study covers the 
following points: 

(1) Identify User Objectives. The user and 
system analyst project team will conduct a careful study of 
user objectives. The purpose of the system effort is to 
develop systems for the user; therefore, his objectives 
should be stated as clearly as possible. Some of the advan- 
tomes of this approach follows [35]: 

- Management will understand what is to 
be accomplished. 

- The study team will have a well-defined 
met oÉ goals. 

- There will be a framework for evaluating 
we final outcome. 

C Analysis of Actual Procedures. This study 
is concerned with the analysis of present procedures. Gen- 
erally this analysis will accomplish the following: 

- Identify the objectives of the existing 


procedures. 
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- Produce a diagram of the information flow 
Maca tinsg input sources, data concentration, processing, 
outputs produced, output distribution, organizations involved 
mi the process, and the time associated with each activity. 

- Highlight possible problem areas. 

- Identify the costs and benefits of the 
procedures. 

- Determine whether user objectives are 
satisfied. 

(3) Redefinition of User Objectives. After 
studying actual procedures, the system project team can 
develop a better understanding of user requirements, and 
possibly, a redefinition of objectives will be necessary. 

(4) Select Performance Criteria. The idea 
behind this activity is to establish the criteria by which 
the effectiveness of the subsystem is to be measured. This 
activity will continue throughout the development effort, 
becoming more detailed and refined with each stage. Some 
examples of criteria are cost and time savings. 

(5) Identify Alternate Solutions. The system 
project team will establish a set of possible solutions for 
Biemoubsystem under study, alternate Solutions could be the 


following: 


Do nothing., 


Develop a manual system. 
= inpro e present system 


- Use service bureau. 
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ICON tracto: 

- Develop an integrated manual and computer 
system (In-house). 

- Develop a computer system (In-house). 

(6) identi tys Resources and Constraints. Thie 
system project team and the user will proceed to identify all 
the resources that are available for building the subsystem. 
Examples are manpower, budget, hardware, software, and other 
resources. 

Constraints are all those limitations that 
will affect the subsystem development process. These limita- 
tions can be management directives, time required for imple- 
Mentation, budget, organization policy, and legal and regu- 
latory documents [3]. 

Once the resources and limitations are estab- 
lished, a preliminary feasibility study can be conducted. 
This evaluation will consist of checking whether the proposed 
solutions can satisfy the user objectives and meet the per- 
formance criteria under the imposed limitations. 

(7) Select Preferred Solution. The user and the 
A A e project team will study the alternate solutions and 
they will select the preferred one. The system project team 
a act as a council. Considerations about advantages and 
disadvantages of each alternative will be made clear to the 
user. Since systems are develaped for the user, he will have 


the final decision in selecting the preferred solution. 
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(8) Prepare Proposed Subsystem. If other than 
the "do-nothing" alternative is chosen, the system project 
team will proceed to elaborate a draft of the proposed sub- 
system. The most important considerations for this study 
are the following: 

- Make a complete and detailed statement 
of the user's requirements. 

- Identify all subsystem outputs. 

- Identify all subsystem inputs. 

- Determine the necessary processes needed 
to produce the required information. 

- After completion of previous steps, pre- 
pare a block diagram of the major functions to be performed 
by the subsystem and their interelationships to each other. 
Beemripgure 5.2 as an example. 

- Identify all necessary files and their 
contents. This section of the study will be carried out by 
the Database Design Team. Both System Project Team and 
Database Design Team must have a close relationship through- 
autre system Development Process. 

- Draw the information flow diagram for the 
proposed system. 

- Draw the general flowchart for the subsys- 
tems. 

- Identify resource requirements: Budget, 


Manpower, and Equipment. 
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- Prepare an implementation schedule. 
- Prepare a feasibility report. 
UMEN teNbunceitEonalW5pecrfications. This is a 
Br eription of the system, in terms of the functions it must 
perform. Input and output rates, response time, thruput, 
database (file) content, inquiries, and block diagrams are 
some examples of the specifications that need to be written 
during the preliminary analysis. 
(10) The Relationship of Manager and System 

Analyst during the MIS Analysis. The responsibilities of 
Manager and System Analyst will now be discussed. The pur- 
pose will be to show what they should expect of each other 
during the different stages of the system development pro- 
cess. This guideline has been adopted from reference [17]. 

System Analysis is concerned with reviewing 
the existing system with emphasis on the constraints under 
which the present system operates. It is also concerned 
Ann defining the project and scope of the projects to be 
analyzed. 

Manager's Duties 

SETS pumtery responsibility is to provide 
wenas with a complete and accurate picture of the pre- 


sent system. 


Review present documentation with the 


analyst. 


Discuss information requirements. 
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System Analyst's Duties 

- Make a thorough review of the existing 
system: how it works (documentation); how the users per- 
Ernest to work; and how’ it actually works. 

IND Nw ICCSHEdO Wd Input and output of 
Present system; processing required to convert input to 
output; quality of present output; problem areas in existing 
system; policies under which existing system operates; inter- 
facing of present system with other existing systems, 

een a CONpLetc=rlIsSt ©f aoecuments and 
wo ated: reports, forms; data source, volume, purpose, 
meeaiency, acclracy, and time lag of input to output. 

Error scontrolsaacaınst errors. 

- System flowchart (if necessary). Overall: 
an agreement between the system analyst and the manager regard- 
Mohe operation of the existing system. 

After examining the above list of duties it was 
concluded that the following items should be added: 

Manager: 

- Review and discuss with the analyst the 
Selection of the performance criteria. 

- Select adequate solution from the set of 
alternatives. 

- Assist analyst as needed in preparing the 
proposed system. 

Analyst: 


Separe a rough draft of the proposed system. 
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Aopare the feasibility report. 

(11) Documents Generated by the Analysis. The 
feasibility report is the main document generated by the 
analysis. It contains summarized information of the previous 
activities. This document allows the steering committee to 
analyze and make its decision regarding future svstem develop- 
ments. 

The feasibility report is prepared according 
to the documentation standards of the particular organization. 

The System Requirements Specifications is 
another report prepared by the system project team to specify 
requirements that a proposed subsystem must meet. 

DaesPunctronal Specifications is a general 
document that broadly explains the components of the subsys- 
tem and what functions they perform. 

Ia addition to the above reports all other 
pertinent information created to date are const and added 
to the portfolio of documentation of the analysis. 

(12) MIS Refinement. The feasibility report is 
Bulent ted to the steering committee for its review. From the 
o reports teat it has received to date, it extracts 
information about subsystems that were not considered in the 
Em conceptHeH, subsystems that will be cancelled, sub- 
Scene that will be necessary to combine, and the like. This 
information will keep the MIS updated with the information 
requirements of the organization. Also an arrangement of the 


Paro rities is considered. 
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Eee MIS DESIGN 
The overall idea in this phase is to provide a detailed 
design of the systems that will be implemented, establish 
software and hardware requirements, design the database, 
program and document the system. 
1. Preliminary Design 
The starting point of the preliminary design is the 
documentation generated during the preliminary analysis. 
Since the system development process is a matter of refine- 
ment, this looping-back to earlier stages of development is 
always present during the system life cycle. Evaluate 
Alternate Design Approaches, Select Preferred Design Approach 
and Write Preliminary Design Specifications, are the primary 
points treated in this stage [18]. 
a. Evaluate Alternate Design Approaches 
Using as main input the system requirements and 
fmc tional specification document, the system project team 
evaluates a set of alternate design approaches to carry 
out system requirements. Typical design approaches for a 
computer based information system will depend on the proces- 
sing mode, the data organization, and the hierarchical 
approach. A general overview of these approaches follows: 
By Processing Mode 
- Batch. 


- On-line (Also include real time and time sharing). 
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By Data Organization 

EE Uc Processinp'Appraoch. 

- Data Base Approach. 

By Hierarchical Approach 

- Centralized Processing Systems. 

- Decentralized Processing Systems. 

b. Select Preferred Design Approach 

After a careful evaluation of the alternatives 
îs completed, the user and analyst proceeds to select the 
design approach that best fits requirements. Once again, 
the user has the final decision in this selection, but the 
system project team must have discussed with the user the ad- 
vantages and disadvantages of the possible alternatives 
within the framework of the resources, constraints, and per- 
formance criteria. As an example, the design could be based 
w ero eSSing approach, a decentralized computer system, 
amd batch actualization. 

c. Write Preliminary Design Specifications 

The system project team, so far, has reviewed 
ew Sting systems, proposed a new system, evaluated alternate 
solutions, evaluated different design alternatives, and selec- 
ted an approach. The next step is to translate the design 
ama schetowa set Of written specifications that describe the 
system. These are used to direct the efforts of the system 
project team and the users. The main activities that are 


undertaken in this phase are the following [19]: 
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el ienotify master files, working files, data 
volumes, frequency of updating, retention time, data access 
methods and response time required from files (database). 

- Determine the file (database) organization and 
Layouts. 

:2:pecutol)nput rates. input layouts and the like. 

- Define reporting requirements, volume, frequency 


End distribution. 


Determine controls and audit procedures. 


Identify computer programs and manual procedures 


required. 


Prepare program Specifications. 


Identify hardware and software requirements. 


Revise estimate of operational costs of system. 
oy mWetailedwdesign 

The main objective of this phase is to obtain a de- 
tailed system design for implementation. This means that the 
entire system has to be defined in terms of information flow 
database (files), inputs and outputs, procedures, program 
specifications, and test specifications. The main product of 
this phase is the deatiled system specifications. At this 
point computer programs can be written and the selection and 
evaluation of hardware and software can take place. 


The following paragraphs indicate the main activities 


aech are undertaken- in- this phase. 


50 





a. Identify Human Engineering Problem Areas 

This activity involves identification of all 
areas of the system where human engineering is required to 
optimize personnel effectiveness, comfort, and safety. Work 
space layout, controls and displays, ambient conditions, 
training requirements, and task performance aids are examples 
of these areas. 

The human characteristics identified here will 
subsequently be incorporated in procurement and design speci- 
fications of input/output equipment, communication networks, 
work facilities, job aids, training courses and other items 
related to the personnel subsystem. Some human factors 
considerations are: identification of critical human opera- 
tions, specifications of aids to these operations, rules for 
man/machine interfaces, initial training guidelines and iden- 
tification of organizational problem areas [3]. 

b. Develop Manual Forms 

In this activity the design of all the manual forms 
that feed information to the subsystems are completed. In 
designing these forms care should be exercised to ensure that 
eaetredestegn Optimizes the function to be performed. The use 
of format design techniques and human engineering factors are 
considered. The key points to remember in the design of 
manual forms are: forms must be designed for each use, the 
form usage should be self-explanatory, all necessary informa- 
tion to fill out the forms must be supplied. This is normally 


murten at the back of the forms. 
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pUeveloeN CDoOINEs 
Aee TevorEes Of Lhe particular subsystem under 
study are developed at this stage. These reports are pro- 
duced by the computer. The report design should be oriented 
toward use by a human being. 
a Designing the Database 
The introduction of the database concept has 
changed the traditional system development process. At this 
Stage, the project team designs the information files con- 
tents, organization, and access methods. However, in the 
database approach this design has taken effect at the begin- 
ning of the system life cycle. For this reason a more 
detailed study of the database design will be treated in 
Appendix B. 
e. Define Systems and Audit Controls 
As the project team has the design responsibility 
for those systems which it proposes, it also has responsi- 
bility for ensuring that the overall system will safeguard 
the organization by preventing the loss of operational capa- 
bility due to internal system faults and hardware failure. 
The database control group is responsible for preventing 
deliberate destruction, accidental destruction, or corruption 
Ot data. 
Some of the measures taken to protect against 


these failures are the following [19]: 
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(1) Physical Security. Physical security can be 
further subdivided in the following areas: 

OSN Hazard Protection. Covers fire, 
Mood. storm and riot protection. 

b) Limitation of Personnel. Covers all 
the measures taken for preventing unauthorized personnel 
Me@ees> to the computer facility. Strict controls are enforced 
when operating with sensitive data. 

(c) Theft Protection. Measures taken for 
protecting data against burglary or lost. The use of TV 
cameras for monitoring the computer operations, the use of 
burglar alarms, and the like are typical examples of these 
measures. 

(d) Hardware Protection. The parity check 
is an example of hardware protection. It can be said that 
they are check points built in the hardware itself. 

(e) Computer Room Procedures. Deals with 
the procedures used for handling the operation of the com- 
pu oom. Examples are the rules used for labeling tapes, 
and preventive maintenance of hardware. 

(£) Library Control. Procedures used for 
controlling all program files, operating systems and utility 
software, as well as total system documentation. Only in this 
way can it be assumed that in a run the correct version of the 
pre@ram was used with the correct files. 

Cae eeens Controls. This term is used to cover 


all those controls which are specific to a particular system. 
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meme, or these controls will be included within the system 
itself, i.e. they can be done automatically by the computer, 
while others will be implemented manually by the user. The 
following list identifies some of the major system controls. 

= Control Totals. A given data element 
1s summarized as a separate clerical process and compared 
against the same summarized data element processed by the 
computer. 

(b) Supervisory Checks. This concept deals 
with the monitoring of subordinates work by any level of 
management. 

(ce) Pome Cheeks. The basic principle is 
that the data is examined to see if the value is a reasonable 
value for that data item. 

fi Check Digits: he basic principle is 
that a reference number, like employee number, has a supple- 
mentary number added to it. This supplementary number has an 
~ene eic relationship to the rest of the number. This re- 
lationship can be checked by performing some arithmetic opera- 
tions over the complete number. 

(e) Verification. This concept deals with 
Sica tion ot the input data before it is fed to the 
system. This is widely applied in installations that use 
keypunch machines or data entry systems, 

(f) Sequence Checks. Certain data elements 
must occur in specific sequences and these sequences can be 


checked by program. 
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(g) Sample Checks. It is often useful, 
especially in the manual areas of a system, to institute a 
En con Only a portion of the total data volume. It is 
Euer to the quality control checks used by manufacturers 
in production lines. 

m dic Controls. These are a set of controls 
designed to meet legal and audit requirement. The basic 
nes ement in this connection is the provision of a trail, 
called the Audit Trail, which enables the calculations per- 
formed on a certain item of data to be traced back through 
each processing step to the source. 

f. Identify Computer Programs 

Figure 3.2 shows the functions that the subsystems 
accomplishes. At this stage these functions are combined 
and/or subdivided into program descriptions. 

Modular programming is used to segment the program 
nto 1ts logical parts or routines so that each routine may be 
programmed independently. Modularity allows independent 
HII nostr modeles. There isa different set of factors that 
need to be considered depending upon whether programs are 
E ed for batch or on-line processing. These factors as 
seen by Hice [3] follow: 

m norane actors to consider in defining batch 
programs are: 

- Similar data base actions. 

- Common logic requirements. 

- Generic or specific similarities in outputs and 
inputs. 


59 





m cuumredESottware utility intervention. 

zu Teer credepregramesıze. 

- Intermediate output requirements. 

The important factors to consider in defining 
real-time programs are: 

-inputi transactions.: 

- Processing sequence. 

- Specific routine requirements. 

- Output transaction requirements. 

- Required software utility intervention. 

- Logical processing pause or interrupt require- 


ments. 


opecified program size. 

Programs are first defined and then subdivided 
into a modular arrangement. This method produces program 
segmentation and facilitates load module development. 

omnes Sevection of Sene computer WenguageWthat 
is used for coding the programs takes place at this stage. 

g. Develop Logic, Flowcharts and Tables 

The broad information flow has been identified in 
the preliminary analysis and preliminary design phases. In 
the detail design phase this should be reviewed and broken 
down into a greater level of detail. A master flowchart of 
the subsystems is then produced, showing all inputs, files, 
processing stages, error recycling, and outputs of the sub- 


Systems. Care must be taken to identify the different time 
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Peters. For example, frequency of reports, and length of 
retention of files and input data. 

An important tool to use at this stage is decision 
Mbs. They are invaluable in defining the relationship 
between data, programs and users. Decision tables in conjunc- 
tion with flowcharting are the major means of developing a 
system design. Advantages of decision tables are: 

- They constitute a defined and orderly method 
of documenting analysis data. 

- They are independent of the processing method, 
and may be used in any situation where decision must be made 
Met regard to the availability of computers or other 
equipment. 

- They lend themselves to automation because they 
use binary logic. 

- The tabular approach to procedure definition 
aids the analyst in visualizing relationships and alterna- 
eaves. 

imei rales of charting allow the detection of 
omissions and inconsistencies. 

- Their simple format allows changes to be made 
easily and the effects of such changes to be easily recog- 
nized. 

- Debugging is reduced because of the approximate 
error-free logic with which the final decision tables are con- 


srrücted. 
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- There are rules to determine the internal con- 
ENEtenev ot decision tables. This is not true for flowcharts. 

- Decision tables can be input to one of the 
decision table processors which has been developed, and it 
moll produce coding in a particular language. 

ha Write Program Specifications 

toe program specifications basically consist of 
the following documents [20, 21]: 

- Diagrams of the preprinted input/output forms. 

- Layouts of input and output records of the 
subsystem files with all data fields clearly identified. 

- Master and detailed flowchart of the subsystem 
md its programs. 

- Decision tables. 

- Relationship between programs and subsystems. 

- Information as to hardware, utility software, 
and programming language to be used. 

- Processing characteristics. 

- Test requirements. 

The program specifications allow the project team 
to design, code, and test the subsystem programs. A set of 
specifications will be written for each program within ‘the 
subsystem. 

i. Develop Human Procedures 

Human procedures are a series of statements that 

establish a course of action to be followed consistently 


under the stated conditions. The main idea behind this 


Sie 
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Esncept is to increase work simplification and improve human 
effectiveness. All the procedures that will be carried out 
by the human being in connection with the subsystem will be 
analyzed and broken down into small pieces so that they can 
be minutely examined. This approach often causes an immed- 
iate visualization of areas that can be improved. Also 
associated with this concept are procedures for filling out 
KE corms, distribution of reports, verification of data 
before automatic processing, and operations to be carried 
üt in case of disaster or emergency. It is pointed out 
that the establishment of these procedures implies training 
for both the users and data processing personnel [3, 22]. 
j. Write the Subsystem Hardware and Software Require- 

Ments. 

This step involves a complete analysis and revi- 
Sion ot all the previous steps. The requirements for hard- 
ware and software for a particular subsystem will be summarized. 
These requirements are subsystem dependent, but basically the 
Brojesr team should establish requirements for [3, 23]: 

- System processor(s). 

- Amount of primary memory. 

nds and numbers of auxiliary storage devices 
Buch as printers, card readers, and card punches. 

- Other equipment such as a system console, chan- 
nels, hardware floating-point option, or storage protection 


tor multiprogramming. 
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- Data communication facilities, such as termi- 


NES S. multiplexors, 


Srs and switches, 


concentrators, modems, front-end proces- 


- Operating systems. 


- Languages compilers. 


- Utilities. 


- Data management systems. 


- Software packages. 


- Database systems. 


This summary should be presented in a way similar 


to figures 3.3 and 3.4. They will be very useful for config- 


uring the computer system for an MIS. 


Develop 

Ies 

eomrcol group write 
mest specifications 


tem/system testing, 


Subsystem Test Plan 

step the project team and the database 
the test specifications. Basically the 
cover manual procedures testing, subsys- 


acceptance testing, and hardware testing. 


Ic considerations at this stage are the following [3]: 


- Identify the special software that will be used 


we port of the test which is not part of the system under 


test. An example is the use of test data generators. 


- Give the location(s) where the test will take 


Eurer thie data(s), and participating organizations. 


Mes tablish personnel requirements. 


- Establish equipment requirements. 


- Specify test objectives. 


- Specify test extensions. 


- Specify test constraints. 
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FEATURE 


FUNCTIONAL CHARACTERISTICS 


Processing Characteristics 


Source 


Tax Considerations 


Deduction Types 


Data Base Files 


Outputs 


Other Functions 


Data Base Throughput 


OPERATING ENVIRONMENT 


Main Storage 


Auxıllıary Storage 


Input/Output 


Source Language 


Figure 3.5 
Source: 


Ref. 
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PAYROLL 


Weekly, biweekly, semi- 
montnhiy, monthly, pay- 
rolls, hourly, salaried 
personnel, premium pay, 
overtime. 


Time card data, file 
maintenance data 


Federal, state, city 


12 voluntary/employee; 
all have upper limits 


Payroll master file on 
tape, ancillary files on 
disc 


Bes 


Es zolsenazcheersare 
isters; time sheets; 
laboradi tribution, 
deduction reports; pay 
checks/statements 


Deposits earnings in 
checking, savings accounts 


1,700 char/employee 
1,200 checks/hr 


SEDE ES 


i Clie | eveyone l5 mb), 
3 tape (9-track, 800 bpi) 


Card reader (1,400 cpm); 
line printer (1,100 lpm) 


COBOL ANS 


Example of a Subsystem Summary 


[23] 
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TRANSACTION PROCESSING 


Ferrer ONAL CHARACTERISTICS 


Processing Characteristics 


Input Sources 


Frequency 


Data Base Files 


Outputs 


Other Functions 


Data Base 


Response Time 


On line production ftor 
the creation and update 
of files and directories 
for file/directory main- 
tenance. 


Manual keyboarding of 
full line entries or 
changes to line entries 
from 50 sources (termi- 
nals). 


Erequeney ot aetivity 

is constant from 30 ter- 
minals with remaining 20 
terminals contributing 
at random intervals. 


Files and directories on 
disce 


Call-ups of line items 

at remote terminal with 
edit responses to updates 
or changes. 


Output of information 
into formalized reports 
and listings is performed 
iñ local batch mode. 


Approximately 180,000 
accounts with an average 
OE SDUEChardccounte 


Terminal response less 
than 10 sec. 


Figure 3.4 Example of a Subsystem Summary 
for an On-Line Application 


Source: 


[23] 
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TRANSACTION PROCESSING 


OPERATING ENVIRONMENT 


Main Storage 


Auxiliary Storage 


Input/Output 


Source Language 


Communication Controller 
or Processor 


Alternate 


Communication Line 
Adapters 


Eraure 5.4 


Determined by number of 
simultaneously active 
users and operating sys- 
tem requirements. 


SOUTO bytes dise 
storage for files and di- 
rectories plus operating 
system requirements. 


Remote teletype-like 
device or CRT. 


Conversational. 


Communication controller 
with ability to terminate 
16 or more communication 
lines, performs line or 
page buffering, line mul- 
tiplexing, and polling, 
as well as line control 
and interface functions. 


Depending on the other 
demands of the computer 
system, a small communica- 
tion processor could be 
substituted in place of 
the controller, but for 
most intallations this 
would not be required. 


Asynchronous line adapters 
fOrel. 200= bps. polled 
(shared) private line com- 
munication circuits asyn- 
chronous line adapters for 
dial lines operating at 10 
to 30 cps. All transmis- 
sions use the ASCII char 
set and teletype (model 
SS IDO Oc Line wd 1s 
cipline). 


(Continuation) 
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OPERATING ENVIRONMENT 


Communication Lines 


Remote Terminals 









Figure 3.4 


TRANSACTION PROCESSING 


Six private line VOICE 
Circüits. hostine five 
terminals each; 10 in- 
dial standard voicegrade 
lines. 


Teletype-like CRTs or 
keyboard printers with 
[oL MAD char S 
Printers mma, DIENTE = 
ferred over CRTs for 
off-line editing and 
documentation purposes. 


(Continuation) 
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Ae tablish eriteria for acceptance test. 

This specification must be detailed for each sub- 
ewen and refined in the testing phase. The main products of 
this stage are the establishment of a subsystem test plan in- 
Bine test schedules and the creation of the appropriate 
test data. 

User participation is creial in establishing the 
en eria for acceptance of the test: 

BENE eee Detailed system Specifications. Sys- 
tem specifications are a set of documents that define the 
internal working parts of a new computer-based system. The 
major activities of this phase are as follows [24]: 

- Work out a basic design for a programming 
system to support the user's operations. 

- Flowchart the user's staff operations as 
they will be carried out under the new system. 

- Develop final specifications for computer 
hardware and other equipment needed to develop and operate 
the new system. 

- Finalize contract terms with vendors of 
software packages. 

- Complete the design of programming subsys- 
en, file and database structures, and program modules, in- 
cluding those needed for conversion of the user's current data 
files. 


- Plan user documentation training. 
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[Ensure Chat internal auditors review the 
specifications, negotiate changes, and plan their own pro- 
cedures for auditing the user's operations under the new 
systen. 

- Agree on criteria for accepting the sys- 
tem as operatıonal, or terminating the development effort. 

- Revise the cost benefit study. 

- Review plans for the remainder of the 
project. 

The final documents that are generated at 
this point depend on the standards established by the organi- 


zation. However, the following list is a typical example: 


Detailed manual procedures. 


Flowcharts, tables and program specifica- 


Cons. 


Input and output specification. 

- Final design of files (database), data 
parameters, and internal tables that will be shared by the 
Moe ams within the subsystems. 

- Final hardware and software requirements 
a par cicülar subsystem. 

- User document specifications. 

- Revised cost analysis document. 

- Test specifications. 

x ccecpmponeeucriteria. 


- Subsystem implementation plan. 
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m. The Manager and the System Analyst during the 
Preliminary and Detailed Design 

This guideline outlines the duties and responsi- 
bilities of Manager and System Analyst during preliminary 
and detailed design. It was adopted from reference [17]. 

Manager's Duties 

- Develops an understanding of the systems ana- 
EN s Job, philosophy and attitudes. 

onem dscxosntsccneu5cent review over the output 
@e the analyst. 

- Primary duty is to review proposed system for 
adequacy. 

Can be performed on a subsystem basis, but entire 
system should also be reviewed. 

- This type of review should prevent major pro- 
blems from occuring in the implementation stages of the sys- 
tem. 

- Discuss proposed system with his staff with 
amalyst present. 

Systems Analyst's Duties 


- Prepares the following documents: 


System flowchart 
- Program flowchart 
Zi stzesseontrols 


Procedures manuals 


- Document design and layout 


- Input 
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= OBER UT 
write des@en and layout 
- Timing estimates 
- Conversion to new system 
- Run times 
=e CGS es 
- Conversion to new system 


- Maintenance and up dating 


i 


List of organizational changes 

- Job descriptions 

- Notify personnel department if union issues 
involved. 

Overall: An agreement on what the proposed system 
should do, costs, involved, and its effect on personnel. 

n. Documents Generated at the Preliminary and Detailed 
Design. 

Although documentation will be treated later in 
this discussion as a step of the system development process, 
the reader has noticed that whenever applicable a reference 
to the basic content of a report, a manual, a procedure, or 
the like has been made. The idea emphasized here is that 
documentation is a continuous process that moves along with 
the system development process. Also, lack of documentation 
is one of the major problems in system development. The ideal 
Situation is that the project team will not move ahead until 


all the documents of a step are completed. 
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In-NNdcasGt presenting this discussion at the 
end of each main phase is to stress the importance of docu- 
mentation and to identify the most important documents that 
should be generated at each stage. Preliminary and detailed 
design generate the following documents [25, 26]: 

(1) Subsystem Requirements Manual. This is a 
description of what the subsystem is to be, what has to be 
done, and what is to be achieved. 

(2) Present Subsystem Manual. This is an over- 
all examination of the documentation generated to be sure 
that, in fact, agreement and full comprehension have been 
AM eved as far as the existing subsystem is concerned. 

(3) Proposed Subsystem Manual. Same as above 
but concerned with the proposed subsystem. 

(ie Program Specifications. A detailed descrip- 
bem Of all programs. This document covers programs descrip- 
Bn. file or database description, processing logic and 
ilowchart. 

Gest ope cifications] It isiadescription 
he objectives of the test, expected results, and overall 
pest plan. 

aX NE call EDesionoSpecifscatuons. Mt specifies 
precisely how the subsystem will do what the functional 
Bo srjycations said it should do and how it will satisfy the 
requirements stated in the subsystem requirements specifica- 


tions. 
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3. Configuring and Selecting the Computer POU oie nt 


This section covers hardware/software configuration 
and selection process. Before going further in this study a 
background will be given in order to show what has been 
happening with the MIS development since the initiation of 
pue study. 

When the organization decided to move to computerized , 
systems, a steering committee and a system development team 
were appointed. 

The steering committee conducted a study of the organ- 
ization and determined the major functions that were performed 
within the organization; such functions were the basis for 
identifying the potential systems that could be automated. 
Furthermore, each one of these systems was broken down in 
other small pieces which made up the potential subsystems 
within each system. The general structure of the MIS took 
form at that moment. 

The next consideration of the steering committee was 
to establish a set of priorities for each system and subsys- 
em. 

The system development team came in and conducted a re- 
mined study of the potential systems and subsystems. The 
Be procuct of this activity was the elaboration of the feasi- 
balaty report and functional specifications. With the approval 
of the steering committee, the system development process con- 
tinued and reached the point where the detailed design speci- 


fications were established. As part of this study, a document 
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called the Subsystem Hardware/Software Requirements was 
1ssued, 

Although the term subsystem has been used throughout 
Ius discussion to mean a particular module of the entire 
MIS, it does not mean that the study of several other modules 
has not been undertaken in parallel. At some points the 
steering committee/system development team will consolidate 
all the information generated by the subsystems. This approach 
meld be used several times throughout the System Development 
Process as a means of controlling system integration. 

Selection and evaluation of the computer system is 
a point where the information generated by the subsystems 
must be consolidated. 

The hardware/software evaluation team (see Appendix 
Pee Comaucts this study. A thorough revision of the neces- 
Sary documentation generated to date is carried out. Neces- 
sary changes are made as they are observed. 

The evaluation team proceeds to summarize the hard- 
ware/software requirements of each subsystem. Possibly, the 
Mesteway of doing this is by using matrices, where each row 
mepresents a particular subsystem and the columns represent 
epecitic requirements. At least two matrices are necessary, 
ale for the hardware, and the other for the software require- 
Does Figures 3.5 (a) and 3.5 (b) show this idea. The 


figures were derived from reference [23]. 
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iMemicxtestep 45 to study the matrices that have been 
created, delete the redundant requirements, and decide on 
the most reasonable alternatives. For example, several sub- 
e tems can specify the use of a printer for their outputs 
but it does not necessarily mean that several printers are 
needed to satisfy the requirements. One or two printers, 
perhaps, can satisfy the needs of the installation. Situa- 
tions like this are analyzed by the evaluation team. 

When the analysis is completed, hardware and software 
totals can be written. These totals are a good approximation 
to the hardware/software requirements. However, these require- 
ments can be refined a little more. The following factors 
show why this is necessary: 

- Not all design phase subsystems will finish simul- 
taneously; therefore, many hardware/software requirements will 
not be ready at the consolidation stage. 

- MIS is a dynamic system; therefore, hardware/soft- 
ware requirements will change through the life of the MIS, 
influenced by the growth of current applications and/or the 
addition of new ones. 

- Establishment of requirements do not obey any mathe- 
matical formulation; they are a product of human estimation 
Eud therefore, prone to errors. 

The refinement will consist of extrapolating future 
hardware/software needs for a reasonable period of time. How 


much is reasonable is difficult to determine but the 
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organization cannot afford to have the system underpowered 
at the beginning of the production phase. 

The evaluation team can proceed now to set up the 
computer system configuration that will support the MIS im- 
plementation. 

Having established these requirements, the next step 
ls to prepare the Request for Proposal (RFP). 

The RFP contains the following sections [27]: 

a. Management Information System Requirements 

This section should contain the MIS requirements. 
This 1s a summarized information compiled from the subsystem 
requirements as defined during the Preliminary and Detailed 
Design phases. 
e Evaluation Criteria 
In this een the criteria oy i wnich the pro- 
posals are to be evaluated should be explained to the vendors. 
This includes both the factors to be evaluated and their 
relative values. Generally speaking the factors that will 
be considered for evaluation may be grouped in Mandatory 
Requirements and Desired Features. Under Mandatory Require- 
ments are listed all those items that are indispensable to 
meet the organization's objectives.  Desired Features are 
/ helpful but not essential. 
SS stem Support 
The kind and extent of vendor support necessary 
for attainment of all system objectives should be stated, and 


may extend beyond maintenance and training needs. Programming 
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assistance, special subroutines, documentation support, and 
other special requirements for which the user has a genuine 
need, may be herein defined. 
d. Benchmark Data 
The benchmark programs to be used should be 
supplied along with sample data. 
e. Bidder's Conference Datas 
The bidder's conference is a formal presentation 
to the vendor, by the user, of his system requirements. The 
date for the conference and a general explanation of its 
purpose should be included in the RFP. 
f. Proposal Due Dates 
The proposal due dates should be explained along 
With a clear description of what will happen to late propos- 
als. 
g. Vendor's Demonstrations and Presentations 
Some time after the submission of the proposals, 
the vendors should be afforded the opportunity to explain 
their proposals. Having run benchmarks, the vendors should 
be required to provide demonstrations. 
feecomersactine Conditions 
The vendor should be informed that any promise 
Dues Will be written into the contract and that the con- 
tract will have to be signed by a corporate official. 
i. General Comments 
MES section should contain any instructions on 


the format of the proposal, such an arrangement of information 
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within the proposal, number of copies to be submitted, and 
the like. 

Mme approach OL this discussion is oriented toward 
the evaluation of a new computer system. However, other 
logical means could be used to satisfy the MIS requirements 
Is 

SUSCI SLIccIUDGo DHIBeJu. 

—Rentingocomputer time. 

e asing a surplus computer. 

sino time sharing services. 

col shared computer facilities. 

A financial analysis of the above alternatives, con- 
sidering their advantages and disadvantages, can be performed 
in parallel with the study for purchasing a new computer. 

In parallel with the submission of the RFP to the 
vendors, the evaluation team must prepare the evaluation 
plan. This plan explains in detail, the steps and the consid- 
erations that are followed for evaluating and selecting the 
computer system. Basically, this plan covers the following’ 
aspects: 
a. Proposal Evaluation 

itewPGOposalS submitted by the vendors are exam- 
ined thoroughly. The key points to look for in the proposal 
are completeness of the information requested, accuracy and 
validity of the information, ambiguities, ommissions or 
deviations from requirements, and proposals that do not meet 


the mandatory requirements. Vendors that do not satisfy 
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mandatory requirements are disqualified. Vendors which did 
not submit complete information are asked to supply it in a 
messonable period. ot time. After that, the field of compet- 
ing vendors should be narrowed to those who have been respon- 
ane to the requirements of the request for the proposal (RFP). 
pee tldaram@adre Specitications Evaluation 

The evaluation team proceeds to study all the 
hardware specifications supplied by the manufacturers in the 
technical manuals. The purpose of this. study is to determine 
Bene offered" Systems meet the RFP specification. The fol- 
lowing checkpoints may be considered when evaluating hardware: 

- CPU (exeuction time, registers, addressing mode 
instruction set, memory capacity, multiprocessing, number of 
channels which can be attached, etc.) 

- Channels (channels command, throughput, buffer- 
ame, etc.) 

To es Memory (capacity, buffering, access time, 
@mamster rate, expansion modules, overlap, etc.) 

ne te Tapes (number of tracks, density, 
transfer rate, rewind speed, read backwards, etc.) 

- Printers (character set, throughput, characters 
per line, etc.) 

- Terminals (buffered/unbuffered, synchronous/ 
asychronous, dumb/intelligent, programmable, human engineers 
features, transmission mode, special features, function keys, 


etc.) 
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-= Communications Units (polling) transmission 
Ane transmission rate, control units, buffers, etc.) 

- ‘Sump weiey of Operations., 

“Expansion Capability. 

Reliability (canbe given by the manufacturers, 
or can be obtained from system's users outside the organiza- 
eion). 

- Back-up Equipments available in the localities 
close to the installation. 

- Physical facilities required (space, air condi- 
moning, electrical, floor ceiling, etc.) 

- Delivery Schedules. 

- Hardware Costs. 

- Maintenance Costs. 

- Pechnical Documentation Support. 

e. Software Specifications Evaluation 

This is a similar study as above but concerning 
the software. Basic checkpoints are the following: 

- Operating Systems Features (schedule, memory 
management, I/O control, partitioning, multiprogramming, 
melbtiprocessing, interrupts, system generation, memory required, 
Bes). 

- Languages Support (Cobol, Algol, Fortran, 
Assemblers, Report Generator, Simulation Languages, etc.). 

- Utilities (sort, editing, debugging tools, 
emeors diagnostics, file manipulation, etc.). 


- Special software 
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:mcustustrcoMPackages (BMBNESPSSS etc.)^ 
- Mathematical Packages. 


- Database Management System (ADABAS, TOTAL, 


IMS, DMS, etc.). 


software). 


- Compatibility (with other equipments and 


= leteecommunications suitability (device handling, 


Seon processing teatures, re-entrant coding Capability, bit 


manipulation, etc.) [20] 


conducted, 


[19]. 


Paeerlities , 


Reno e 

- Software Documentation. 

erase Or Learning. 

- Delivery Schedules, 

Vendor Evaluation 

A detailed evaluation of the manufacturers is 
Emphasis will be placed on the following points: 


- Personnel Support (numbers and qualifications) 


- Vendor Support (maintenance, training, back-up 
feemmreal assistance, etc.)7 

- Quality of Provided Documentation. 

- Image. 

- Vendor Demonstration. 

Evaluation Methods 


The technique(s) or method(s) that will be used 


for evaluating the computer system will be established in 


the evaluation plan. Some of these methods are listed below 


B 7$] 
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- Simple and Sophisticated Mathematical Formula- 
i en. 

and Timing. 

Use of Benchmarks: 

se of Sinulation. 

SNe Nes mand ScCOTPTIns. 

- Minimum cost for fixed performance. 

- Maximum performance for fixed cost. 

= COSte Va luce 

- Present Value. 

Whe first four techniques are used for validation 
of system timing. Through these techniques the evaluation 
team will ensure that the timing requirements of the MIS will 
be satisfy by the proposed configuration. 

A brief explanation of some of these methods is 
presented. 

(1) Use of Benchmarks. This technique involves 
the running of several applications which are representative 
of future computer workload on the vendor's equipment. The 
ideal situation would be to run actual applications but some- 
mimes this is difficult to accomplish because they are being 
designed. 

When actual applications are not available, 
the evaluation team uses models that simulate typical appli- 
cations. Also, benchmarking programs can be found in the 
market, or can be adapted from other organizations. 

The test consists of recording tne computer 


run times of the application and uses the comparative times 
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of the application and uses the comparative times and result- 
ant costs as a determinant in selecting a vendor. 

It is not advisable to use only benchmarks 
for selecting a vendor because so many other factors have 
equal importance. This technique can be combined for example 
with the costvalue technique when making the final evaluation 
[28]. 

(2) Use of Simulation Methods. Through this 
technique the computer hardware, software, and applications 
Programs are represented by a program model in order to dev- 
elop performance and cost estimates for the computer workload 
Om a variety of computer configuration [28]. 

This technique is costly and time consuming. 
Some simulators packages, available from manufacturers, are 
SCERT (Systems and Computer evaluation and review technique), 
GPSS (General Purpose System Simulator), CASE (Computer Aided 
Sistem Evaluation), and CSS (Computer Systems Simulator). 

(3) Wei hts and Scoring Method. In the weights 
ande seores approach [28] the characteristics of a computer 
system are divided into major classes such as: 

- Hardware 

- Software 

- Implementation 

- Support 

- Performance 

: Expansion Potential 


=- Documentation, etc. 
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Each of these major clasisfications are further 
subdivided until the degree of fineness desired is obtained. 
Now, the resulting set of characteristics describes the compu- 
ter system. Each of these characteristics will be assigned a 
factor (weight) according to the importance that they represent 
to the information systems. 

Also each major subdivision will have a weight 
factor assigned. For example hardware will have a weight as- 
signed. It can be subdivided into CPU, Mass Memory, Printers, 
etc., each one of these subdivision will have their own weight 
factor. The CPU can be further divided into execution time, 
Begrsters, number of channels allowed, etc., with a weight 
factor assigned to each one. 

Edem proposal is scored according to the 
degree in which they possess these characteristics. Now, 
the score is multiplied by the weight assigned to each char- 
Heteristic. 

The total of the scores of the characteris- 
tics of a subdivision are then multiplied by the weight 
assigned to that subdivision. The total of the scores of all 
subdivisions is then multiplied by weight for the major class- 
ification or division such as hardware. The resulting figure 
gives the total score for hardware. This procedure is re- 
peauweasfor all major classifications. The resulting score 
yields a measure of total performance score of the system, 

Now, the cost of each system is considered, 


and it is divided into the total performance score. The 
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Bong figure is—the Total Performance/Cost. This figure 
meecaleulated for each vendor and compared. The candidate 
with the highest figure is selected. 

(4) Cost-Value Technique. In this technique, 
cost is the main criterion for determining the winner. The 
cost-value technique recognizes the necessity of evaluating 
the desirable features offered by the various computer sys- 
tems proposed. 

Simply stated, the cost-value technique 
amounts to taking the total cost of a system proposed and 
then deducting the cost values of all the desired extras 
included in that proposal. The difference represents the 
derived cost of satisfying the mandatory requirements stated 
in the specifications package. The system having the 
lowest derived cost for satisfying the mandatory requirements 
becomes the system selected [27]. 

t.  Emaltiation Schedule 

THis section of the evaluation plan will contem- 
plate date, locations, and personnel that will participate 
in the evaluation process. 

Whenever appropriate in this thesis some guide- 
lines have been given showing the responsibilities of the 
users and the development team during the system development 
process. However, this time the presentation will be slightly 
different because several groups can be involved in this 


phase. The concepts were derived from reference [29]. 
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(1) User Gromp Responsibilities. The user group 


is represented by the steering committee. 

nanatin of the activities that will 
be performed by the data processing, financial, and legal 
units. 

- Negotiation with vendors. 

- Development of feasibility study and cost/ 
benefit analysis. 

- Development of the acquisition study file. 

Selection. ol mBequired contfigumationk 

(2) Evaluation Team Responsibilities. 

- Assist user group in negotiations with 
vendors regarding technical aspects. 

- Evaluation and final approval of the hard- 
ware, software or service offered. 

- Assist user group in preparing vendor's 
financial options to review by financial unit. 

- Assist user group in planning the hardware/ 
software implementation. 

- Maintenance of a tickler file by date of 
expiration for lease and maintenance agreements. 

- Prepare report of results of the evalua- 
tion and submit it to the steering committee. 

nacen coup Responsibilities. 
- Analysis of the vendor's financial options. 
namens for and analysis of competitive 


DIN T leasing funds, if leasing is the selected alternative. 
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- Determine tax benefits to be derived by 
the acquisition and which party can exercise these benefits. 
(4) Legal Counsel Responsibilites. 

- Review of all agreements before commit- 
ment by the steering committee. 

- Recommendations of supplemental clauses 
to be amended to vendor's contract that will adequately pro- 
tect the organization's interest. 

- Participation in negotiations between 
vendors and steering committee on matters relating to con- 
wne law and special clauses to protect the organization's 
interest. 

The final consideration in this stage is 
concerned with the documentation that is generated in order 
to support and document the evaluation process. 

(5) Documents Generated During the Computer Sys- 
tem Selection and Evaluation Study. 

(a) MIS Hardware/Software Requirements. 
This document is prepared by the evaluation team and will 
consdst basically of two two-entry matrices (one for hardware, 
the other for software) where rows indicate systems and sub- 
doean thie will run on the computer and columns indicate 
howdwere or software requirements. 

(b) Hardware Diagram. A schematic showing 
the different hardware components of the proposed configura- 


tion and their relationships. 
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KNNSoOFCWUre Dasram. As above but involv- 
ing the software and the functions that will be performed. 

(d) Evaluation Plan. Explained in the 
discussion. 

(e) Request for Proposal (RFP). Explained 
W the discussion. 

Gaye Report of the Evaluation Result. This 
report will explain in detail the results obtained during 
the evaluation. Vendor proposal results will be presented 
ranked by some order, as for example descending order start- 
ing with the best result and ending with the worst one. 

(g) Physical Requirements Document. Once 
the desired computer system has been selected the physical 
Tequimements for its installation will be established. It 
Deus cover space, floor, ceiling, air conditioning, power, 
costs, and other similar requirements. 

4. System Programming 

Programming is am activity that follows the detailed 
Æ o on phase. The input document to this activity is the pro- 
gram specifications developed in the detailed design phase. 

The purpose of programming is to translate the pro- 
gram specifications into executable computer programs which 
may be tested. 

In many system developmental efforts, the development 
of the manual procedures of the subsystem is overlooked and 
ignored in the shadow of the programming effort. This is a 
serious oversight because computer programs are only as 


Se@eetive as the manual processes which they support. 
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MEC COVers the process Of verifying the program 
specifications produced in the Detailed Design phase, pro- 
ducing detailed diagrams, coding the programs, documenting 
the programs, compiling and desk checking the programs, and 
finally debugging the programs to the point where they may 
be turned over to personnel responsible for system testing. 

The system project team is responsible for this ac- 
mty. Special care is called for in the case of multipro- 
ening and multiprocessing due to the increased complexity 
qe the programming effort [3]. 

a. Problem Analysis 

Problem analysis began in the Preliminary and 
Detailed Design:phase. However, it has been said that the 
system development process is a matter of refinement; there- 
mome. a careful review of the program specifications, before 
Proececaing to the design phase, is a worthwhile effort. 

Wirataets "expected at this time, is a good defini- 
emand understanding of the problem by the project team. 
fhis situation is covered by obtaining answers to the fol- 
lowing questions [29]. 

- What must the program do? 

- What are the inputs for which the programs 
must do its job? 

- What outputs are required? 

are enesaceeepteplesrioning time of the pro- 
gram? 

- How much storage (in memory and mass devices) 


can be used? 


88 





- What other programs or operating systems must 


this program operate with? 


SHOVES Che program relate to the total envir- 


onment? 
- Which are the time and budget constraints? 
- What standards or conventions are to be followed? 
- Which hardware/software configuration will be 
used? 


These and others similar pertinent questions cover 
the major decision points and allow the project team to start 
design. For each of these questions it is helpful to ask not 
only what is allowed but also what is not allowed. 

Sometimes the user does not have a specific answer 
to a question, in this case the project team is free to design 
that element in any way, but further discussion, with the user, 
concerning the approach taken is necessary in order to make 
certain that it is acceptable. 

All questionable areas found during the revision 
EM erem specrficatrons are clarified with the user before 
proceeding with this phase. 

Neta nal product ot this stage is the establish- 
ment of the program objectives. 

Eee poctan Deston 

Once the problem is thoroughly defined, program 
ger on can begin. The project team reviews, one more time, 
eiempreeram Specifications. Specifically, the program design 
approach which was previously established in this document. 


The steps to be reviewed are the following: 
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- Identify major functions that the subsystem 
must accomplish. 

- Identify subfunctions that will be performed 
for each major function. Divide subfunctions in small mod- 


Mes) aS necessary, according to the degree of fineness 


mecurred. 

SEU) gumertion, subfunction. amd modules 
me tationship. 

weevtewmure block diagram that indicates functions, 
subfunctions, and modules relationships. Generally speaking, 


top-down design and modularity have been used when performing 
previous steps. 

= Review flowcharts. 

- Review tables and decision tables. 

- Review completeness of the documentation of 
meevious steps. 

- Review of the final product - the program speci- 
fications. 

All the necessary corrections are performed before 
continuing to the next steps: coding, debugging, and documen- 
tation. 

c. Program Coding 

Program coding should be structured and performed 
according to pre-established standards. Readable and efficient 
coding is learned only through continuous practice writing 
programs in a disciplined way. For this reason guidelines 
that may help in writing programs will be offered in this 


section. These guidelines are the following: 
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- The design must be completed before any code is 
developed. 

= Project team {or individual programmer) should 
read carefully the program specifications, become familiar 
with them and discuss extensively and in detail any point 
that has not been made clear. 

- Project team (or individual programmer) should 
be familiar with the chosen programming language, operating 
System, utilities, and hardware configuration where the pro- 
call run. This point is difficult to accomplish when 
En sorsanizatıon 15 planning for its first computer. 

eo team or individual programmer) should 
choose a coding technique prescribed by the installation. 
Top-down coding and bottom-up coding are the most used tech- 
niques. 

In top-down, coding is generated starting with 
the Main program and then going down step-by-step to the 
lower levels of the program. These lower levels may be sub- 
routines, nested subroutines, functions, and priruitives. 

In bottom-up, coding is generated starting at the 
lower levels, progressing up to the higher levels, and fin- 
fia to the main program. Top-down coding is the preferred 
method. 

- Programs should be written with simplicity in 
mind. Complex coding techniques should be avoided whenever 


possible. 
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- Machine independent programs should be written 
whenever possible in order to assure portability; however, 
efficiency may be reduced. 

- Weinberg [30] suggests that it is a good prac- 
tice to encourage each programmer to present his program 
design and coding, to all members in the same project team, 
for their review and criticism. 

- Programs should not be data dependent.  Gener- 
ality allows easy modifications and leads to fewer errors. 

- Programs should be fully documented, internally 
as well as externally. See the section on Program Documen- 
tation for more details. 

- The use of structured programming and indenta- 
tion makes program listings more readable. In a time-sharing 
environment indentation techniques can be automated. 

- Programs should be desk-checked before submis- 
sion to the computer. 

Ano inclusion of controls at strategic places 
in a program should be the practice. Control totals, check- 
dee, data boundaries control, detection of invalid data, 
such as using alphabetical where numerical should be used, 
and the like are examples of controls that may be included 
in the coding. 

This practice is a useful tool in debuggin and 
testing. 

d. Program Debugging 
"Debugging is an art: the art of finding the nature and 


location of an error once its existence has been estab- 
lished." [31] 
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Debugging is sometimes confused with testing whose 
objective is to show the presence of errors in a computer 
program. 

Like coding, debugging is also a matter of exper- 
ience and continuous practice. Experienced programmers can 
fix "bugs" in a program more easily than novice programmers. 
ürererm bugs, just introduced, is a synonym for errors. 

The purpose of this section is to present some 
of the methods and philosophies used in debugging programs. 
Sources of error,debugging tools, and planning of debugging 
runs are some of the most important topics covered below. 

(1) Sources of Error. A large percent of errors 
that appear in a program are introduced by the person res- 
ponsible for its coding. All programmers, ranging from exper- 
ienced to the novice, can introduce errors in a program. 

It can be said, that bugs have been passing 
from generation to generation of programmers. Errors com- 
mitted by programmers of the 1950's are still committed by 
Iuossrammers of the 1970's. It is a good practice in organiza- 
tions to keep a record with historical information about this 
matter. Identification of the errors, what caused them, ana 
how they were fixed, is an invaluable reference in a data 
processing organization. 

The following is a list of come of the com- 
mon sources of errors that appear in computer programs [31, 32]. 

(a) Keypunching and Clerical Errors. In 


EBEN ee ory fall all those errors originated during the 
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transcription of source documents (as coding sheets) into 
cards, tapes, or other recording media. Confusion between 
letter Z and number 2 is an example of this category. 

(b) Uninitialized Variables. Variables 
that are used before being initialized. Some compilers have 
Beatures that set up all the uninitiliazed variables to a 
predetermined value at compilation time. Normally, they are 
mitialized to zero. 

(c) Sharing Variables Among Many Modules. 
Two or more modules trying to use the same variable or memory 
Gaon tor their temporary storage. 

(q Control and Logic Errors. These errors 
w :1cult to find and also difficult to explain. Branch- 
ing to the wrong labels and calling the wrong modules are 
examples of this category. Generally speaking, in this 
category fall all those design failures which the programmers, 
Bomsciously, wish not to happen. 

fe) Array Subsector? Out or Bounds. If 
happens wnen during computations the program begins to 
address before the start or past the end of the assigned 
array memory area. 

CEN proper Arithmetic Operations. During 
computation division by zero or negative squared root are not 
allowed. These are eamples of improper arithmetic operations. 

(g) Syntax Errors. This error happens when 
Mer program statements do not conform the syntax rules estab- 


lished for the programming language. 
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(h) Data Errors. Normally, these errors 
happen when provisions are not taken to anticipate the 
ranges of data. A mathematical operation performed on an 
Eusbetrce piece of data is a typical example. 

(1) Missing Program Cards, Out of Sequence 
Hoeram Cards, Additional Program Cards. Errors due to 
these causes can happen when careful handling of card decks 
B not observed. 

(j) Using the Wrong Versions of the Program. 
lNucegse of out-of-date versions of a program may be a source 
OM errors. 

(2) Debugging Aids. 


"Debugging aids are stethoscopes necessary to isolate the 
cause and location of an error." [32] 


Debugging tools, debugging aids, and debug- 
ging techniques are synonums. They can be described as a 
set of tools used by the programmer in order to facilitate 


the debugging process, i.e., the process of finding and 


locating errors. The most typical debugging aids are:  dumps, 


traces and dynamic debuggin techniques (DDT). An explanation 


Eum hem follows [31, 32]: 

(a) Memory Dumps. In this technique the 
contents of core memory can be printed at any time during 
the execution. Normally, the output is given in a hard-copy 
dessteesiıke a printer, but outputs to tapes, or disk are also 


possible and printed later. 
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The information obtained concerns the 


status of a program at a given time. This information is 


printed in machine code and requires the programmer to under- 


stand machine language and to be able to relate the machine 
language to his high-level language program. 

(b) Traces. This is another technique very 
useful in debugging. Traces can be implemented by the pro- 
gaammer ın the structure of his program or can be a part of 
the software package supplied to the installation. This 
technique causes some portions of the memory to be printed 
ames, or under conditions specified by the programmer. 

A trace can be used to see if the program is executing in the 


sequence in which it was written, and to see if the variables 


have the desired values stored in them. 


(c) Dynamic Debugging Tools (DDT). This is 


a more powerful tool than memory dumps and traces. There 
are different kinds of DDT packages that can be implemented, 
They are the following [31]: 

- Stand-alone DDT is one of the simplest 
and is often used to debug programs on small machines. 

The main characteristic of this package 
is that it handles its own terminal communication with the 
programmer. The I/O communication is handled without the 
intervention of the operating system. 

Stand-alone DDT does not allow the exe- 


emeromeof other processes while it is in use. Also, it does 
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not allow the programmer to examine or modify a program while 
Ee is running. 

- Time-sharing DDT differs from stand- 
alone in that the terminal communication is handled by the 
operating system. This means that the operating system can 


perform other functions while it is waiting for the program- 


mer to provide terminal input to the time-sharing DDT.  How- 
ever, the program that has been debugged cannot run concur- 
rently with the DDT. 
- Real-time DDT is the most complex form. 

It allows other programs to execute while it is waiting for 
input from the programmer's terminal. The program being 
debugged and DDT can run concurrently; therefore, modification 
or examination of the program is possible while it is execu- 
ptm. 

(sy) Planes a Vebtecing shun. the ideal of plan- 
ning a debugging run is concerned with finding and fixing 
the bugs with a minimum expenditure of programmer and machine 
time. 

A typical debugging plan may cover the fol- 
lowing steps: 

(a) Desk Checking. Desk checking begins 
with desk (card deck) checking. A careful examination of the 
card deck will minimize the possibility of missing, out of 
sequence, or extra cards. 


Programmers who prefer to punch their 


programs should have them verified by a keypunch verifier. 


97 





TieM@ieces > tepeic eto produee a Misting of 
the source deck. The listing is compared against the coding 
wear: and to the flowcharts instruction by instruction. At 
this step the programmer will try to find differences between 
the logic of the code and the flowcharts. If modular and/or 
structured programming were used their value would be apparent 
at this stage. 

Whenever possible, the programmer should 
submit his code and flowcharts to somebody else on the project 
team for review and criticism. 

(b) Test Data Cases. The next step is to 
pare a set of data that can flow through every path of 
the program at least one time. Since a program may be sensi- 
tive to certain data values as well as data ranges test cases 
should be established for a variety of values [29]. 

The test data cases are prepared con- 
sidering valid input data values to the program and also data 


Eu cydecthe range-ot permissible values to test the error 


detection capability of the program. 

Test data cases can be obtained from 
the users, asking other members of the project team to pre- 
pare them, or through the use of test data generators. 

(c) Controlling the Debugging. The debug- 
ging process should be conducted in a controlled fashion, 
rather than in an indiscriminate manner. The following steps 


should be followed for successful debugging: 
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= Programs should be run for the first 
time with a minimum amount of data. The purpose of this pro- 
cedure is to clean the programs of syntax errors, keypunch 


errors, and the like. 


- Once a program has been cleaned, it 


can be executed with the test data cases to see how the pro- 
gram behaves. Special attention is placed on verifying the 
mea tronship between a set of inputs and their respective 
Sputs. 

- All the program listings produced 
during debugging are carefully marked and filed for reference. 
The idea is to have historical information of all the steps 
pen to correct the bugs. 

- The last consideration is that the 
programmer should be familiar with the computer system and 
software packages, specially those parts of the software 
useful in debugging, and with computer room procedures. 

e. Program Documentation 

The process of documenting the program starts 
during the preliminary and detailed design. Some of these 
documents have been explained throughout this discussion. 
These documents cover functional block diagrams, flowcharts, 
tables, decision tables, files and database organization, 
m output forms, manual and computer procedures, and all 
other aspects of the program. 

The documents referenced above can be considered 


as the external documentation of the program. Programs can 
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be also documented internally. This technique is called 
intraprogram documentation. 

All the programming languages, including assemb- 
lers, allow the insertion of comments within the program. 


Intraprogram documentation, basically, should cover the 


| 


following: 

- Program identification, either by name or 
encoded form. 

- Version of the program. 

Erca tlon dute. 

MOLa tOr S nane. 

- Brief description of the purpose of the pro- 
gram. 

Ie ac DP ro rana subPeutline; or £Zuneeron, 
Ame: description of its purpose. 

- A listing of all the mnemonics that identify 
variables with their full names and a description of their 
use. 

- Two or three statements describing important 
processes or calculations. 

The insertion of comments in a program do not 
reduce its efficiency because they are not considered at 
execution time. 

The use of indentations when writing programs 
produces neat and readable documents. 

There are other documents derived from a program, 
Ux manual and operator's manual, but they are discussed 


in the documentation phase of the system development process. 
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5. wüssuUemntation 


"Documentation management is a demanding task. To make 
use of a well known analogy, final system documentation 
is much like the weather: Everyone talks about it but 
DoNSBe does anything about it." [33] 
By this discussion, a section dealing with the docu- 
ments that must be generated at each step has been inserted. 


If the documentation is generated at each stage during the 


development of the system, there is no need for a final sys- 


tem documentation phase. 

The major portion of a MIS development is the publi- 
cation of documents. From the beginning the project team 
issues a stream of forms, reports, memos, flowcharts, and 
diagrams. Each of these must be prepared, reviewed, revised, 
circulated, revised again, and maintained. Later on computer 
eo ams will appear in the project and they create a need 
Mas t1ill more documents. 


All of these plans, specifications, memos, and file 


fesemuiptions document a project. They establish the reasons 


Borsstartins the project, record decision points made during 


development, reflect changes in plans, and after months, and 


Q a years of work, onla a few describe the complete compu- 


ter system [34]. 

Documentation is the only mean through which the com- 
munication between a computer based-system and personnel who 
operate, maintain, manage, or audit it, can be established. 
The preparation of good documentation unambiguously defines 


the following: 
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"UP OS cmo the system or propram. 


ROCCA Lor TUMMINE it. 


Format and flow of data through the computer systen. 


Controls included to ensure the validity and inte- 
grity of the data being processed as well as the results. 

- Logic of the operations that the computer and humans 
perform. 

e eaa limitations and assumptions. 

a. Problems Resulting from Inadequate Documentation 

some of the specific problems caused by inadequate 

documentation are summarized below [35]. 

(a Programs Must be Rewritten. Whenmit is 
necessary to modify or to change a program, the absence of 
documentation will make going through the listing program, 
understanding it, and figuring out the possible changes, 


almost impossible. Even for the original programmer it is 


hard to understand his program after a few months. The result 
is that modifications that could be easy to implement will 
cause a program to be rewritten for lack of documentation. 

(2) Systems Must Be Redesigned. The considera- 
tion is the same as above, but now several programs may need 
medication. If documentation does not exist the whole sys- 
tem must be redesigned. 

(3) Excessive Time to Make Modifications. The 
amount of time required to go through the program listings 
can be long or even unsuccessful, after wasting considerable 


amounts of time due to the lack of documentation. 


102 





C e cule Auditing Process. Lack of documen- 
tation makes it difficult for auditors to identify internal 
controls provided in a system; therefore, system audits may 
not be accomplished, 

b. Causes of Inadequate Documentation 

In the system development process there are many 
factors that may cause inadequate documentation. When ade- 
quate controls are not exercised, designers and programmers 
will devote their efforts to have a working system as soon 
as possible. Arter the working system is obtained they start 
Lune about documenting the project; but the "paperwork" 
involved in this activity is so overwhelming that they will 
never finish the documentation of the system. If documenta- 
tion is completed the system will probably be poorly docu- 
mented because the designer or programmer lacked time and 
must recall many things from memory. 

The other reason for inadequate documentation 
concerns enforcement. If standards are established, manage- 
ment must establish some control points during the develop- 
ment activity in order to ensure that the necessary documents 
are generated in the appropriate stages. Management must 
Wotealiow the project to proceed to other phases of develop- 
ment if the appropriate documents were not completed in the 
preceeding phase [35]. 

Some approaches to the solution of the documen- 


tation problem are the following: 


es 





- Establishment of documentation standards. 

- Management review and enforcement. 

> Establishment of technical writing staff who 
will produce well-written documentation from the manuscripts 
of programmers and system designers. 

- The use of design and documentation techniques 
like HIPO (Hierarchy plus Input-Process-Ouput), developed 
by IBM. A detailed description of this technique can be 
found in reference [36]. 

c. Documents Required in the System Development 
Process 

This section will present a summary of the most 
important documents that will integrate the documentation 
portfolio of a MIS; each one of the referenced documents is 
necessary for each subsystem that comprises the MIS; these 
documents as quoted in reference [25] are the following: 

ee SWaelysis and Feasibility otudy Report. This 
is a proposal to management requesting approval of a new 
stem and the budget for it. 

(2) System Requirements Specification. This 
specification is prepared by the system designer to specify 
business requirements that a proposed system must meet. 

C Eneti onal Specifications. Ihis is a gen- 
eral interim document that broadly describes what the system 
will consist of and what functions it will perform. 


Aera Besien opecifications. This is dev- 


eloped from the functional specifications. It specifies 
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precisely how the system will do what the functional specifica- 
tion said it would do and how it will satisfy the requirements 
stated in the system requirements specification. 


(5) Program Specifications. These are prepared 


pou cach program or processing entity that is a component of 
an application system. 

(6) File or Database Specifications. These are 
prepared for each file (or database) that is a component of 
an application system. They specify the fields (or data 
elements) and records that make up the files. 

CNN C-te5pEchEicatiYons. These specifications 
document the requirements and results of program, subsystem, 
System, acceptance and parallel testing. 

(8) System Maintenance Manual. This manual 
provides a master reference and cross-reference to all sys- 
tem components. 

O On pu ter Processing  Pecilications- Ihis 
specifies all the job processing information required by com- 
ue Operations for the routine processing of every system 
ob. 

(10) General Information Manual. This provides 
a system summary for executives and top system-user management. 

(11) System User's Manual. This manual is used 
to train user personnel and as a reference source for solving 
simple operational problems. It is primarily intended for 
supervisory, administrative and clerical personnel in user 


departments. 
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(12) System Procedures Manual. This manual pro- 
step-by-step instructions for all activities, jobs, and 
tasks associated with the system. 

(13) Terminal Operators Manual. This provides 
instruction for the support of dedicated use of on-line ter- 
minals. 

If all the documents reference above, and other miscel- 
laneous documents, are generated in the appropriate phase of 
the system development process according to the standards of 
content and quality established by the organization, the 


mm product will be a well-documented system. 


C. MIS IMPLEMENTATION 

In this stage all the necessary activities for making 
the developed system operational and shifting control to the 
user are carried out. 

Testing, implementation, operation, maintenance and 
follow-up and system cessation are the main topics discussed 
Views stage. 

l. Testing 

Testing of computer programs is a frequently ignored 
BEIM Us little appreciation for the scope of the 
problem, to the point that not even among the data proces- 
sing people is the concept of "testing" universal ES e 

The objective of this discussion is to present an 
overview of the current techniques and strategies that can 


be applied to testing. 
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The key question in testing is the following: Given 
a computer program, how can the programmer determine whether 
or not it will do exactly what it is supposed to do? 

This section attempts to answer this question. Basic 
definitions, scope of the testing problem and testing methods 
aene main points treated in this discussion. 

a ARDE rini tionrand Concepts 

Going back to the preliminary steps of the sys- 
tem development process, the reader will recall how the MIS 
Erg cruetured.  bsgure 3.6, shows a block diagram of the 
structure of the MIS parts by levels. Each one of these 
levels indicates where testing needs to be performed. Level 0 
(zero), at the bottom of the figure, shows the lowest and 
simplest unit of testing in an MIS, the module. As the 
testing team progresses up in that diagram the units of 
testing are relatively more complex, and therefore, more 
complex to test. The following are a set of basic definitions 
and concepts that form part of the testing terminology used 
throughout this discussion. These concepts were quoted from 
ae erences [31, 32, 37]. 

(1) Module. A module is a collection of instruc- 
mU sufficient to accomplish some logical funetion. It is 
sometimes defined in terms of physical constraints, such as 
mae idea that a module should not consist of more than fifty 
statements. There is also an almost general assumption that 
a module is not normally useful unless it is combined with 
other modules to form a larger self-sustaining entity (i.e., 


a program). 
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C MEb5sSBam A program is a collection of in- 
structions which, when combined with appropriate data and 
Gomerol information is sufficient to accomplish some well 
denned function. A current tendency exists in the data 
Processing field to form programs from a different number of 
modules that when put together can perform a meaningful 
zunetion that is the combination of the isolated functions 
accomplished by each module. 

(3) Subsystem. A subsystem is a collection of 
programs organized in order to accomplish a larger and more 
complex function that would normally be done with a simple 
moram (1.e€., payroll). 

(4) System. A system is considered to be a 
collection of programs and/or subsystems sufficient to accom- 
plish a significant coherent application or major function 
mme., personnel system). This word is often used to des- 
cribe any collection of programs provided by the vendor with 
the computer hardware (i.e., the operating system). 

Ee e o Ero Ue cae programmers 
Jones a software error which can be repeatable and con- 
sistent or transient. This term is normally used when refer- 
muto Logic errors, instead of syntactically incorrect 
Statements. 


C Testine. ost Lm eo eC Ne  picOcess nor execut- 


ing a program with the intention of demonstrating conformance 


coa peer ications., It is pointed out that during testing the 
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main idea is to stress the program so that if errors are 
esent, it will fail. 

Cor oort A Proof is an adctempt to findi errors 
in a program without regard to the program's environment. 
Assertions are established about the program's behavior and 
then mathematical theorems about program correctness are 
derived and proved. A proof does not involve program execu- 
Mon in the computer. 

(Sr Vente tion. A verification is an attempt 
amma errors by executing a program in a test or simulated 
environment. 

(9) Validation. A validation is an attempt to 
find errors by executing a program in a given real environ- 
ment. Verification and validation are often used inter- 
changeably, but they are not the same. 

(EO) Maule Testing. Module testing involves 
testing an isolated module in order to establish its correct- 
ness. 

Bee Poeran Testing. Lt sche process of trying 
to discover errors that appear when all the component modules 
oo cam are put together and executed. The great major- 
ity of errors discovered in this phase are caused by poorly 
defined interfaces between modules. 

Doc nding Upemmmneéther themecsting ys carried 
out in a simulated or a real environment, it will be a verifi- 


Gammon or a validation, respectively. 
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(12) Subsystem Testing. Testing of several pro- 
grams which constitute a subsystem. 


(13) System Testne. iee emne of Several sup 


systems. 


Meer tion Testing It is the verification 
of the interfaces among system parts (modules, programs, and 
subsystems). It can also be referred to as the process of 
verifying the interfaces between systems that form an MIS. 

PEI Ei E Se caco asi red Un dance) 
testing and regression testing. After an error is discovered 
and corrected, in any phase described, the retesting is con- 
ducted again in order to ensure that the errors were removed 
and no other errors appear because of the correction just 
made. Note that this process can be applied as many times 
as necessary. 

Wo) Acceptance Testing. It is tHe Cesting of the 
system or program to user requirements. Normally, the user 
establishes the criteria for accepting the product. 

b. The Scope of the Testing Problem 

The introduction stated that testing is one ot 
the less developed fields in data processing and that people 
in the computer field do not have a universally accepted 
definition of testing. Most programmers, many programming 
managers and almost all non-technical managers drastically 
underestimate the amount of time, energy, planning and re- 
sources (money) that should be devoted to testing. This also 


holds for debugging and maintenance. To illustrate the 


2 


complexity of the problem, some of the statistics that were 
found during this research are presented [31]: 

- The amount of time required for adequate testing 
of programs varies from 30 percent of the total project to 
sUepercent or even higher. 

- Eighty percent of the total money expended on 
the NASA Apollo project was devoted to various forms of test- 
ing. However, there are some schedules that call for two 
years of design and implementation and only one month of 
System testing. 

- The number of bugs remaining in large problems, 
after they have supposedly been thoroughly tested, is rather 
large. It has been estimated that each new release of 0S/360 
contains over one thousand (1,000) errors. Besides, one EDP 
consultant is Oslo, Norway, claims to have counted over 
eleven thousand (11,000) bugs in a recent release of O.S. 

Other consideration that need to be studied 
include the amount of testing necessary to carry out prior to 
the acceptance of a system. Logically, the testing team 
Paola try, during a test, to exercise all the possible paths 
during the execution of a program and to have all the possible 
input combinations represented as test cases. As an example, 
analyze the following diagram: Suppose the program to be 
tested has two input variables and one output variable, as 


depicted below [38]: 


SIS 












Program 


to be tested output Z 





If, for an assignment of values to the input 
variables x and y, the output variable z will assume a cor- 
rect value upon execution of the program, then the testing 
team can assert that the program is correct for this parti- 
SAT” test case. If they can test the program for all pos- 
sible assignments to x and y, then they will be able to deter- 
mine its correctness. Now, if they assume that x and y are 
integer variables, and that the program is to be run in a 
Gomeuter with 52-bit registers, single arithmetic, then there 
EC 237 E pee = 294 possible assignments to the input pair 
(x, y). New, suppose that this program in the average takes 
one milisecond to execute once, then it will take more than 
NN TIIion years to complete the a possible combinations 
ene” input pair (x, y). What needs to be pointed out in 
this example is that no matter how large a practical feasible 
set of test cases the testing team may choose, it will always 
consist of an extremely small sample of all the possible cases. 
This is the basis for the well-known maxim that program test- 
ing can be used to discover the presence of errors but not 
char absence. 


A similar problem arises when an attempt is made 


to exercise all the possible paths in a program. Even though 
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this number is significantly lower than the input combinations, 
it 1s still astronomical. However, a practical means is used 
in order to ensure the minimal acceptable degree of thorough- 
ness of a test. In this process, the flowchart of the program 
is carefully examined, and some strategic points are deter- 
mined where software counters can be inserted. Once the test 
is finished, by looking at the counters, it can be determined 
which paths were not traversed. Test data cases are prepared 
for executing those paths at least once during execution. 
Eiserne 5.7, is an illustration of a simple program with and 
without the counters. 

The counters can be removed from the program after 
the testing is completed. However, it is a good practice to 
Pese counters in a program that is used for production, in 
case more bugs are detected while executing under the produc- 
tion mode, as long as the counters do not degrade performance 
ERNIMaROduce other errors. The use of toggles to control the 
counters, and the use of conditional compilation, make this 
practice more effective. 

The last but not the least consideration refers 
to the selection of test data cases. Test data cases [52] 
should be developed for critical input conditions, options, 
and at the boundaries of all input domains and output ranges. 
Test data cases should also probe the program's behavior at 


Gium@etional boundaries and for invalid or unexpected inputs. 


Therefore, testing of a program must consist of the follow- 


ing three phases: 
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= Teserng the mermal cases. 

- Testing extremes. 

- Testing exceptions. 

In all three of them it is common for the program 
poswecept erroneous data and return an incorrect but believ- 
able answer. This is something that will normally go undetec- 
ted with unimaginable consequences. 

Micmiacombelmnd this concept 1s that programs 
need to be designed to prevent the use of incorrect data, 
otherwise considerable precious time will be devoted to 
Searching for bugs that do not exist. 

C. Testing Methods 

In this section an overview of the testing 
methods is presented and some examples are given. The 
methods presented are the most widely accepted in the data 
processing field. The discussion of the methods is based 
Ciao per Program testing, and this concept can be extra- 
polated to subsystem and system testing. 

A pee Cations mics timp: 15, and muse 
Bees tne first part of the complex system testing procedure, 
anemcan be divided into two main stages: 

(a) System Analyst and the User. During 
the genesis of the system development process, users and 
system analysts meet together several times trying to define 


the user's needs. Interviews, questionaires and other tech- 


niques are used to obtain information and define the problem; 


Miemproedm@er of this process is the so-called Specifications 
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Manual. Only when system analysts and users agree, can they 
consider this step finished. Later it may be necessary to go 
back over the Manual and redefine the requirements. 

(b) System Programmer and Analyst. It was 
established above that the user and the system analyst to- 
Mahler write the Specifications Manual. This is the major 
input that the programmer will have. In case any questions 
should arise, the programmer should contact the analyst. The 
following simple rules can be established to assist the pro- 
grammer in reviewing the specifications and in determining 
their adequacy: 

- The specification manual needs to be 
reviewed in detail for completeness and accuracy; it should 
contain a full detailed description of the subsystem and a 
set of flowcharts, decision tables and/or any other aid indi- 
cating all the programs that make up the subsystem. 

- If the manual is incomplete, unclear, 
Bor sufficiently specific, the programmer may reject the 
Mita] stating in writing the exact reason for this action. 

- If the manual is considered suffi- 
ciently descriptive, the programmer must accept the specifi- 


@ations . 


- Those parts of the manual of major 
interest to the programmer are: 
- Scope of the manual. 
- Problem definition. 


- General description of the subsystem. 


DE 








-uwhbowcharts fOr uthomsupsyscem. 

- Decision Tables, 

PUE sande output layouts: 

- Macro-logic where applicable. 
- Files or databases to be maintained. 
- List of programs and their schedule. 
SCORES. TOM ju) the ODE 
-~ Glossary. 

- After completing the macro-block 
diagram, the system's analyst will review the logic in detail 
with the programmer to insure that the programmer understands 
e requirements specified in the manual. 

- All further changes to the program 
must be approved by the analyst, the programmer, and their 
Supervisors. 

CDe Testine: valine lentils.) welds cechniquctis 
often overlooked, it 1s necessary at the beginning to be 
EEpoa3n that the problem has been clearly stated. 

In desk testing the programmer plays the 
role of the computer; he must follow the logic of the program 
thoroughly and check to see if it matches the specifications 
established in the analysis. During this "walking" through 
the program, the programmer must look for clerical errors, 
missing cards, missing labels, undeclared variables, and 
general legibility of symbols. 

After checking for possible syntax errors, 


the most important part of the desk testing technique follows: 
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the logical flow of the program is verified and tested by 
using a typical sample case, and again, playing the role of 
the computer with the help of paper and pencil. It should 
Dempointed out that special care must be taken in verifying 
prumuerty^or the transfer of control according to all the 
Ar erent alternatives of action that could be present. Also 
the process involves checking those structures whose behavior 
depends on well-defined boundaries and the value of index 
variables, such as iterative loops and data structures like 
arrays and vectors. 

Desk testing does not end with the initial 
run. After detecting and correcting those bugs that appeared 
in the initial run, a new pass should be conducted in order 
to verify the corrections just made and to ensure that no new 
problems arise because of the changes just made. 

After the desk checking is performed the 
Mopram is submitted to the computer, It should also be 
eed out that it is the practice to use the compiler to 
help find syntax errors; although this is a good idea, it 
should be exercised judiciously and all syntax errors cor- 
rected before using the computer again. No attempt should be 
made to execute a program without having desk tested it first. 

eorom o Testing. In thas approach the 
program is merged and tested from the low-level modules up to 
the high level modules. The bottom-up approach normally 


requires two stages: module testing and program testing [51]. 


ED 








(a) Module Testing. It is also referred to 
EN umet" testing. It is considered to be the basic level 
of testing. This test is conducted in the following manner: 

- The modular diagram of the program 
Euouirzed, and all "terminal modules" (i.e., the modules 
that do not call or refer to other modules) scheduled for 
the first phase of testing. 

- The testing process progresses up to 
the upper level modules; upper level modules are tested with 
terminal modules. At this level the interfaces between the 
various modules of the program and the terminal module are 
the key testing points. The first modules tested are those 
that interface directly with the terminal modules. In 
Figure 3.8, an example helps to demonstrate this concept. 

(b) Program Testing. Obviously, at this 
Sage the entire program is tested. The principal types of 
bugs expected to be detected here are the following: 

- Interface errors. 

- Complex controlando cre EOS 
especially those due to bad design of the subsystem or poor 
usage of the modules. 

Now the concept can be expanded to sub- 
system and system testing. 

In the framework of this discussion a 
subsystem has been described as a collection of programs. in 
order to test the subsystem, the module testing approach is 
used. The difference is that now the modules are programs, 


but the philosophy is the same. 
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ENNMUISM-LP TESTING EXAMPLE: The following is a listing of 
ENUccICjous program that consists of ten (10) modules. 


The relationship between these modules is represented by 
the CALL statement. 


Main Program Subprocram B 
Call B EE D 
ac Beni 
CE of Main Program toe of Subprocram B 
Subprocram C Subprogram D 
E. caia E 
Call I s 
Call J 
E of Subprogram C Jame of Subprocram D 


Subprogram E Subprogram F 


EN F CSI ME 
esll G 


Call J Call H 


V End of Subprogram E emd of Subprogram F 


Call H 
Erd or Subprocrem 6 End of Subprogram H 


Subprogram J 


Subprocram G E H 


| Suoorocramn G 


End of Subprogram I End of Subprogram J 


Tig. 3.8 ExaAmPLE or Dorrom-uP TESTING 


Sovece, Rererence L3!] 


12 








A eree like representation of the modules to be tested 


Follows: 
E Program Testing 


"eme -ee a ë ë — 


Module Testing 


Module Testing: a) Test terminal modules H,. and I 
b) Test upper-level modules in the 
Following sequence: 


- Test G with H, and C with I 
- Test F with G, and H 

~- Test E with F,G,H and J 

=. Test O with- E.F O M- and J 

~T est B with 0 EJP oE nde 


Program Testing: To test module A (Main Procram) with the 
rest of the modules. 


rig J 3.8 (con. ) EXAMPLE or Borrom-up TESTING 
Sovece: REFERENCE LIT 


r 








A system has been described in this 
discussion as a collection of subsystems; therefore, the 
above discussion is applied except that modules are now the 
subsystems. The question of when testing will take place is 
a problem with this appraoch. Obviously, the answer is when 
all the subsystems are developed. But it may take several 
years to have all the subsystems developed for a particular 
system, and the reader will recall that the system develop- 
ment 1S a dynamic process. The ideal situation of having all 
the subsystems developed may never be reached. Other factors 
that cause system development to be a dynamic process are 
improvements in hardware and software technology. The writer 
does not have an answer to this question. 

ESI tomcowns lesting. <n ethics approaches. 
the method consists of tests of the program from the high- 
level modules to the lower-level modules. Top-down testing 
Suggests that testing should provide the main program and 
perhaps one or two levels of subroutines as a "skeleton" which 
Ee pately tested. The high-level modules can call lower- 
level modules that may not exist concurrently. During the 
test it will be necessary then, to implement low-level modules 
as dummy modules to simulate the functions of the missing 
modules. 

Top-down testing is not considered a rigid 
approach, but is intended as a philosophy, and it can and 
should be altered as the situation requires. It is sometimes 


quite difficult to implement dummy modules to replace all 





routines that are called by high-level modules; obviously, 
the content of the dummy modules will depend on the type of 
function desired to be implemented, especially when the 
module being called must provide some type of output para- 
meters that are needed by the calling module. It is with this 
concept in mind that the testing team can design dummy modules 
Eso Called stub modules) that will return control as soon 
as they have assumed it. The simple ones only contain the 
executable statement RETURN; others contain enough statements 
to generate random parameters or constant output. In the 
case of utilizing random output, care should be taken in order 
to avoid the generation of data that lies out of range. As 
an example of this, consider a program written to solve the 
following quadratic equation: 

Ax? + Bx + C = 0 

It is known that a valid value for A is one 
mete is not equal to 0 {zero), because otherwise, an error 
EN UussonV by 0 (zero) will occur; if the testing team Is 
using some type of pseudo-random number generator, they must 
ensure that the value of 0 (zero) is never returned in order 
pomadvord this problem. 

Once the "skeleton" has been tested, the team 
can proceed and add one new module at a time until the whole 
program has been tested. Some of the advantages ES S 
approach follow: 

= Due to the fact that only one piece of 


code is added at a time, if something goes wrong, the source 
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and nature of the bug will be usually more easy to 
identify. 

ao Milter mace. Comero: sand logic 
bugs are discuvered at an early stage in the testing process. 

- At a relatively early stage the basic 
Nite of the program is working. 

Figure 3.9, illustrates the concepts just 
presented in a graphical way. 

(5) Big-Bang Testing. The philosophy behind 

this method [37] establishes that all the modules should be 
tested individually and isolated from the others. After 
testing all the modules alone, they must be integrated together 
as a whole for program testing. Obvious disadvantages when 
using this method follow: 

- For each one of the modules to be tested 
dummy modules and module drivers must be constructed. 

- Integration of modules occurs too late 
NN .EDrocess. This will probably cause a delayed detection 
of interface bugs. 

M Debugging oo el, la Snte rac 
Berne teati is testing all the modules together for the first 
tame. and errors could occur in almost any part of the system. 

- It is possible that a working program will 
Met be available during the early stages of the process. 

This method is not recommended for the test- 
ing of large programs, and one of the things that needs to be 


taken into consideration is how the team/individual will 
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TOP-OOWN TESTING EXAMPLE: Using the same tree-representa- 
pud from Fig. 3.89 


Skeleton 





Everything below the line is initially simulated by a 
cumin module. Modules D,E,F,6,H,I and J will be added 
one at the time to the skeleton. 


Fig. 3.3 Examrıe or Tor-Down TESTING 


Sovece. REFERENCE L 317 
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psychologically react after spending long periods of time 
testing the system wihtout achieving tangible results. 

(6) Sandwich Testing. This method [37] com- 
bines the main features of two techniques already presented: 
Top-down and Bottom-up, trying to overcome their disadvantages. 

In this technique both Top-down and Bottom- 
up begin simultaneously; the integration of the system is made 
from both the top and the bottom and eventually meet somewhere 
in the middle. Deciding where to meet depends on the tester's 
judgement and the system's design and structure. 

Some advantages of the method are: 

- Integration is obtained early in the 
Process. 

- A working program will be obtained in the 
early stages of the process. 

- The problem of having to construct stub 
modules tends to be diminished because of the presence of 
the Bottom-up technique. 

Some disadvantages are: 

- It is still necessary to write driver 
modules and stub modules; sometimes these will be complicated 
programs, depending on the complexity of the relationships 
internal to the program. 

SEE CUIT de pe Ane mies To 
stop the different approaches and to start testing the pro- 


gram as a unit. 
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(7) Other Testing Techniques. There are a 
variety of other testing techniques in the field of program 
testing, but most of them are still in an experimental stage 
and require further research. A very brief description of 
seme Of them follows: 

(a) Redundant Programming. The key point 
behind this idea 1s to have two or more independently designed 
Om@eewEitten programs for a particular application. Each 
program will be designed, coded and tested by different teams; 
tne omly thing in common to all of them will be the specifi- 
Salas tor the application. An obvious disadvantage for 
this method is the amount of additional programming and sys- 
tem overhead required [31]. 

(> ee otandardt za Clonee Nhu specs 
the tendency is to reduce the occurrence or presence of 
errors by using general purpose subroutines and packages for 
designing programs. Even the subroutine packages have hid- 
den bugs, but their behavior may be predictable and known. 
This is better than dealing with a special-purpose program 
Wuemnay contain bugs [31]. 

San At RS O pe Ao 
large and complex systems it is common to use simulation, 
which can be very useful for evaluating performance. Ina 
few cases it can also help to discover logical errors, but 
it certainly will not help to find coding errors. 

Schneidewind, in reference [39] shows 
how simulation can be used to evaluate alternatives during 


design and to simulate the detection OR errorsudurane testine: 
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(d) Mathematical Models of Program Relia- 
bility. The requirements of software reliability in the more 
complex systems, have recently led to a great deal of research 
in the development of mathematical models for program relia- 
ENEE”. By gathering statistics during the testing process, 
ene model attempts to predict, in a probabilistic sense: 

- The number of bugs remaining in the 
pussmeam when it is put into production. 

- The mean time between failures of 
software. 

mhne probability that the program will 
enoe uccessfully for a specified period of time. 

This method has been used rather suc- 
cessfully in space projects and in scme defense projects, 
Dat there is still some hope that it could be applied to com- 
mercial systems in a few years [31]. 

d, The Testing Plan. 

The starting point for testing was accomplished 
during detailed design, where the preliminary test specifica- 
tions were written; however, a more detailed plan is required 
at this time for those responsible for conducting the test 
(the testing team). The elements of a good testing plan are 
E]: 

NN Obpectivess» A definition of the goals of 
each test phase: module, program, subsystem and system 


testing. 
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(2) Responsibilities and Schedules. A defini- 


tion of who will perform test case design, development, exe- 
cution, and debugging for each test phase and information 
concerning the place, and the data when testing will be con- 
ducted, 

(3) Tools and Methods. A description of the 
needed test tools, and the testing methods that will be used, 
for each phse, 

(4) Computer Time, An estimate of the computer 
time required for each phase. 

Eon: leumacıons. A description of any special 
hardware or software configuration needed to conduct the test. 

(O)NMNMBSE Case Libraries and Standards. A defini- 
tion of how test cases will be stored and standards for writ- 
lng test cases. 

(7) Tracking Procedures. A description of the 
method to be used to monitor test progress. 

(8) Debugging Process. A definition of the pro- 
cedures needed to report and correct errors. 

(9m Acceptance Criteria. -The criteria that will 
Nets edito judge successful completion of each test phase. 

The establishment of these criteria is the user's responsibil- 
m. 
e. Acceptance Testing 

Acceptance testing is a validation process in the 

ome that 1 tests how the subsystem matches the user require- 


ments. -This test must be conducted by the user organization 
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who designs and writes the test data cases and tries to make 
the subsystem fail. If the subsystem does not fail and meets 
the minimum requirements, it can be accepted for use [37]. 


f. Manager and Testing Team Responsibilities During 


mieelesting Process [17]. 


Manager's duties. 


Establish acceptance criteria. 


- Write and design test data cases for acceptance 


testing. 


Conduct acceptance testing. 


Accept Subsystem. 

Testing Team's duties. 

mci rSmpetestrne M 

Uu usscstctousertorgan,szatronQeUDOpDrebarndne'andescoH- 
ducting the acceptance test as needed. 

- Record and generate necessary documentation 
during testing process. 

g. Documents Generated During the Test Process 

There is a set of documents that serve as input 
to this phase, and they have been generated in previous steps 
of the system development. In general, they cover the follow- 


ing: 


Subsystem design documentation. 


Subsystem and program design documentation. 


Debugged programs. 
To the above documents the following are added: 


- The detailed test plan - already discussed. 


Par 





ne test data cases produced, whose Secon- 
dary purpose is to act as historical documentation for future 


reference, 


A POD con taaan inerte tollowrnseunmbormadtd on: 


mn acteristics of the errors found, location, nature of the 
error, how it was corrected, and information about the test- 
ing process. 
EN ovscen Implementation 

System implementation deals with the concept of bring- 
ing a developed system into operational use and turning it 
over to the user. 

The implementation of a computer system affects both 
the hardware utilization and the personnel that will use it. 

Putting a new system into operation is usually compli- 
cated by the fact that there is an older system already in 
operation. The implementation team has to deal with changing 
from something familiar to something new and different. Some 
of the main activities that make up system implementation are 
the following: Training of personnel, the conversion of 
prosrams and files, the installation and checkout of the new 
equipment, and the beginning of new operations [21]: 

Se enpo or these activitiesirollowsibelow: 

a. User Training 

The idea, here, is to train all those people who 

Abe part of the day-to-day operation of the system to 
be implemented, because it is vital for making the system 
work. Some of the most important points that should be cov- 


ered in a training plan of this nature are the following: 
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- General information about the system. 

- Information about specific operations of the 
system. 

- Give to the user some "hands-on" practice in 
Operating the system, 

- Get some feed-back from the user, 

The last two points are particularly important 
to the successful implementation of the system, because 
through practice the user will become more familiar with the 
system, will gain more confidence on its operation, will 
pinpoint potential problems areas that were not foreseen 
during system design. By using this approach the user becomes 
a participant in the implementation process [2]. 

b. Preparing for New Equipment 

This concept deals with all the activities neces- 
Sary for the installation of the new equipment. This activity 
Started after the selection and evaluation of the computer 
system phase in crder to meet the delivery schedules of the 
Supplier or to build a new computer facility if needed. This 
Ae consists of the following steps: site preparation, 
installations of data processing equipment, and hardware and 
BerWwere check out [21]. 

ER te preparation e duy e Ue mentes 
ae Sary for site preparation were established when the 
computer system was condigured, according to the information 
thatewas supplied by the manufacturers. 

The provision of adequate site preparation 


storage cabinets, magnetic tapes, cards and other supplies, 
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is the responsibility of the data processing department. 
Basically, provisions are established for the ol orales 

- Adequate work space for the personnel, the 
hardware, office material, and the like. 

- Power requirements, established in terms 
of: voltage and tolerance, frequency and tolerance, number 
of phases, and power consumption. 

- Illumination of data processing center. 

OO 

temo: 

ERA ond tue nnm 

- Safety controls, like smoke detection 
equipment, fire extinguishers, and the like. 

(NM t2llatron cot Data Processingt Equipment. 
Once the site has been prepared, the installation of the new 
equipment can take place. The installation is made by manu- 
e turer's personnel with the help of organization's person- 
nen. 

(5) Hardware and Software Checkout. The hard- 
ware and software systems are normally tested by the manu- 
facturer's personnel. Usually this checkout will include 
the running of special test programs provided by the manufac- 
Burers. 

All the hardware system, compilers, assem- 
blers, operating system, utilities, data communication 
equipment, etc., must be thoroughly tested before being 
AS red to” the organization. “The data processing depart- 


ment must be involved in this phase with the manufacturer. 
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A demonstration of the system with some test 
applications is necessary before delivery. 
c. Programs and Files Conversion 

ie Sey pe Of idata conversion can vary according 
to several parameters. They are the following [3]: 

MOT ers on 0 datada that presently exist on 
machine readable media. 

- Conversion of data, presently manual, which 
must be converted into machine readable format prior to con- 
Meson. 

e onwersmon otodata that does not contain all 
the information required for the new files. 

- Conversion of files that exist as separate 
files into an integrated data base. 

- The size of the file being converted. 

Since most systems will have multiple files to 
be converted into one or more new files, the order in which 
the files are to be converted must be considered. 

d. Beginning of New Operations 

mis Concens deals wi tins thememon leh Ore taans Heron 
from the old system to the new one. Basically three concepts 
are discussed: Immediate cutover, phased cutover, and paral- 
iio rocessing. The description ot this process as quoted in 
reference [3] follows: 

(1) Immediate Cutover. The idea is to stop 
operations under the old systems and begin immediately with 
the new system. The disadvantages that this approach has are 


the following: 
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- It will shock the organization - no adjust- 
ment period. 

A rent ora lero whole Process 
must be repeated with dual inconvenience of returning to the 
old system and then implementing the new system again. 

- It requires a very brief period for change- 
over with consequent strain on the organization. 

- It requires scheduling for minimum workload 
period when all required personnel are available. 

The advantages of selecting this approach 
follow: 

- The new system is immediately available and 
can be exploited fully. 

-~ if no major problems occur, the cost savings 
can be very significant. 

(2) Phased Cutover. The new system is implemented 
by phases. This means that part of the operations are carried 
out by the old system and part for the new system. The dis- 
advantage of this method follows: 

- The scheduling of cutover of each phase or 
subsystem becomes very critical and complex. For each sub- 
system there is an alternative of immediate cutover or parallel 
Processing. 

- The organization of the user departments 
and/or the nature of the system may be such that it is not 


possible to implement the system by its subsystems. 
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The advantages of this approach are the 
following: 

- The outputs of the implemented subsystems 
are utilized prior to full system implementation. 

a Failure of a subsystem is NOtTas critical 
and recovery does not involve the whole system. 

- User experience with a well designed sub- 
system will make the acceptance of the remainder of the sys- 
tem easier. 

(3) Parallel Processing. Both systems, the old 
and the new one, are maintained in operation simultaneously 
for some period of time. Both systems will be kept in this 
condition as long as necessary in order to assure a highly 
reliable new system. The disadvantages of this approach are 
the folloiwng: 

- The direct costs can be very high as almost 
complete duplication of processing will be required. 

- The new and old organizational structures 
may be incompatible, making parallel processing infeasible. 

- The volume of work generated by two systems 
may be too large to handle. 

The advantages of this mode of operation 
follow: 

- Implementation will have a system that 
has been fully checked out under actual operating conditions. 

- Failure of the new system will be less 


severe, as normal processing can continue to handle the work. 
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- User personnel will have the time to become 
completely familiar with the new system. 
- The outputs of both, old and new systems, 
will be available for comparison and evaluation. 
"Au 5ystemsOperation 

In this phase the control of the system is passed from 
the project team to the operations group. Now, they have the 
total responsibility for the operations of the system. 

In this phase the system is tested in a production 
environment. From the viewpoint of testing, it is a valida- 
tion process, because how the system behaves in a "real world" 
Ne main consideration at this point. 

Although the responsibilities for the system have 
been shifted from the designers to the operations group, an 
open communication channel must exist between both groups in 
order to solve all those problems that may arise after imple- 
menting the system. In general, these problems can be grouped 
in the following areas [3]: 

- Previously undiscovered errors that become apparent 
when the system is in operation. 

- Changes in the system software that require changes 
Ihe application system. 

- Changes in system hardware that require changes in 
the application system. 


- The implementation of new application systems that 


require modifications to existing systems because of inter- 


face requirements. 





- The growth of applications systems that require 
emanges or redesign of existing systems. 

pee rag riTation oe the User=with the system will 
allow him to discover areas that may be improved, and that 
ps require the modification of the application systems. 

- The above concept is also applicable to the opera- 
tions group who can find areas of the system that can be im- 
proved or changed in actual operational procedures. 

- Changes in external legal requirements may cause 
modifications in application systems. 

Another consideration is operational procedures which 
Gan be grouped in two main areas: 

The first, affects the operations management and the 
second affects the project team. Operations management is 
not treated in this discussion because it is not a part of the 
system life cycle. The operations topics that are of interest 
to and the responsibility of the project team follow [4]: 

a ovstem Comrormity to Installation Operations 
Standards 

Nermalıy in a data processing organization, proce- 

dures are established to govern the computer center opera- 
tions. Systems should be designed in such a way that the 
established standards are not violated. Violations may be 
detected during the operation of the system, and they must 
be reported to the system group for corrective action. 

b. Usefulness of Operation Manual 

Operator's manuals were developed during the 


design phase. They are the communication link between the 
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operator and the application systems. This means that as the 
operator becomes more familiar with the system, he may find 
better ways of processing it than the methods established in 
the manuals. Therefore, the manuals are revised in order to 
improve the operator's productivity and system efficiency. 

t. ZEszeluation of Run Efficiency 

During the system design phase the project team 
1s working under constant pressure created by user demands, 
and tight schedules. The designers devote their efforts 
toward attaining a successfully running system; once the sys- 
tem is running well, they try to improve its efficiency. 

Normally, improvements can be performed in areas 
such as a better use of the hardware and software capabilities, 
mic handling, program coding, timing, and throughput. 

During system operations all the modifications or 
changes must be asked for in a formal document. This formal 
document will be a part of the historical file of the applica- 
tions, and will also be a supporting document for scheduling 
the modifications and for keeping track of all the improvements 
that have been performed during the life of the system. This 
document is known as the request for changes or modifications 
Bud it will be explained in the next section. 

4. System Maintenance and Follow-up 
System maintenance is an activity through which changes 
or modifications in a system are performed in order to meet 
the established requirements of the system. 
This activity begun in the system operations phase, 


where the system has been under continuous observation by the 
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operation group. In that phase was established the necessity 
of recording in an appropriate document all the problems ob- 
served by the operations group or the user. These documents 
are the input to the maintenance and follow-up activity. 

The documents generated in the system operations 
phase are analyzed by a maintenance team; this analysis will 
allow them to establish a set of actions that can be carried 


out to maintain the system. These actions could be the fol- 


lowing: 


No changes. 


Improve the system. 


Replace the system with a new one. 


Discard the system. 

The last three actions must be carefully controlled 
because they may affect other systems in the MIS environment. 
Modifications, although minor, could notably affect the objec- 
tives and design considerations of a MIS. 

It can also be noted that if replacement is the chosen 
action, the system will come under the next step of the devel- 
Opment process, system cessation, and the whole cycle starts 
all over again for a particular system. 

The most critical situation during system maintenance 
is control. Control in this sense covers two points: control 
of the changes that are necessary and control to prevent unnec- 
essary changes. 

ehanges Or modifications that seem to be easy, from 


the user's viewpoint, may cause a significant time consumption 
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for analyst, programmers, operators and the computer itself. 
Also possible side effects may be caused in other systems. 

There are times when the modifications requested by 
the user are insignificant in the sense that they do not 
improve system efficiency, or do not improve operator's 
productivity or do not improve user's work performance. 

One way of dealing with this situation is through the 
A uest for change or modification. 

Basically the report contains the following: 

- Date of request. 

User smdepartmenmteidentiticodsiom 

ASS cen Identification. 

- Change(s) or modification(s) requested. 

me ene ties thatwill berobtained: 

- Costs. This calculation must be performed by the 
data processing department. 

- Signature of the authority that approves the request, 
preferably at middle/top management level. 

Since the report must be signed by an authority of 
the user's department, chances are a more careful study con- 
cerning the need for change will be conducted. 

System maintenance and follow-up is a necessary acti- 
vity in the system development process. 

The roles of the user and the system analyst during 
this phase follows: 

a. User and System Analyst Responsibilities During 


the System Maintenance and Follow-up [17] 
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Maintenance and follow-up must be undertaken if 
ene system is to be successful. Since systems are dynamics 
they require monitoring in order to meet the needs of the 
changing environment in which they function. 

- Manager's Duties 

= Notes changes in environment that affect the 
system. 
- Makes the request for changes or modifications. 

- System Analyst's Duties 

- Audits the system. 
Ao c hedules changes orimoditications accordin? 
to the user's request. 

Overall: “Continuous Monieorine Of the systemeand 
its environment by the manager and his staff and the system 
analyst. 

eos tem. Cessation 

This is the last stage in the system life cycle. 
Systems will be used for some period x time and after that 
they will be discarded. The useful life of the system will 
be dictated by the environment in which it is being used. 
The two main factors that will determine the end of a system 
are the following: 

- Substitution of a system by an improved system. 

- Discontinuance of a system when it is no longer 
Hoel to the organization. 

ono ter and technical factors: 

The continuous surveys made during the system opera- 


Años maintenance and follow-up stages are very useful in 





providing some mechanism for determining when a system has 
mememed Its cessation point. For example, when numerous 
modifications and patches have been made to a system, or if 
new modifications are going to be extensive, the practicality 
of designing a new system should be considered. 

The question arises regarding the MIS cessation point. 
This question will persist because MIS will always be needed 
in an organization because information is necessary for the 
continued operation of the enterprise, whether it be manual 


or computer based. 
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IV. CONCLUSION 


A study of the system development process has been pre- 
sented. This study emphasized the system life cycle, which 
covers the areas of system analysis, system design, and 
system implementation. 

The starting point of this discussion was the conception 
of a Management Information System that could satisfy the 
inrormation requirements of an organization. 

Information is a vital ingredient for management.  Infor- 
mation is necessary to formulate objectives and policy which 
subsequently must be interpreted and communicated to many 
people. The evaluation of these objectives and the subsequent 
decisions and action plans are based upon information con- 
cerning their impact on the organization. If this informa- 
EIUS incomplete or inaccurate, it can limit the efficiency 
of management. The objective of a MIS is to make available 
comprehensive and accurate information, and to provide a sys- 
tematic method of controlling and directing this vital manage- 
ment resource. 

Management information systems do not happen; they have to 
pemunsquely constructed to fit the organization they are to 
serve. The MIS development generally follows a master plan; 
this master plan contains three major phases: MIS Analysis, 
MIS Design, and MIS Implementation. This thesis described 


the development of the master plan. 
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Huc support and participation of the user and the data 
processing group was established as one of the most important 
factors for a successful MIS development. 

The design of a large integrated MIS must provide operat- 
uu DEetirclency and the ability to adapt to inevitable changes 
of the organizational environment within which it must sur- 
vive. Several design considerations are the key to success 
in both areas. Such factors as the analysis of information 
flow, modular design, structured programming, top-down test- 
ing, the implementation of databases - all interact to estab- 
lish the operating characteristics of the system. Each of 
these areas were treated throughout this discussion. The 
future trends in MIS are oriented toward the implementation 


of distributed systems. 
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APPENDIX A 


I. THE SYSTEM DEVELOPMENT TEAM 


The organization of the system development team is another 
of the key points in an MIS success. 

Obviously, the purpose of the system development team is 
to carry out the development of a MIS to its final stages. 
Today, most organizations have their own policies for recruit- 


ing and evaluating personnel. It will be assumed in this dis- 


cussion that through those policies the organization is 
obtaining skilled and qualified personnel that meet the stan- 
dards of quality and knowledge desired by the company. 
Composition of the team involves both representatives of 
the user's organization and the data processing department. 
Prior to exaplining how the team should be organized, a des- 
Erection of the main functions that are carried out by the 


team 1S given. 


A. SYSTEM DEVELOPMENT TEAM FUNCTIONS 
There is almost a one-to-one correspondence between the 


functions performed by the team and the phases of the system 


development process. These functions are: 
1. Analysis and Design Function 


This function deals with the gathering of information 
from the early stages of development, user's interviews, 


analysis of the actual system, design of a proposed system, 
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implementation strategies, and hardware and software specifi- 


cations. 
~ Programming Functions 
Although this function is normally included in the 
design phase, programming is treated separately in this con- 
text. The purpose is to translate the design specifications 
of the system into executable programs that will run in the 
computer system. The use of modular and structured program- 
ming techniques, top-down, bottom-up, or other design methods, 
codification and debugging, are the main activities carried 
mur in this function. 
D Testing Function 
The test of the systems, in order to demonstrate that 
they do what they are supposed to do, is the key activity in 
this function. Selection of the testing methodologies test 
data cases, planning of the testing efforts and other related 
activities are the main functions performed. 
4. Implementation Function 
Once systems are tested, they are put into production. 
The user and the operations group will now have control of 
the system. File and data conversion, operations procedures, 
maintenance and follow-up are the characteristic activities 
performed in this function. 
5. Data Management Function 
The data management function is exercised through 
Aena ta Base Administrator. The activities performed here 


are related to the database (DB) and they are the following: 
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establishment of the data base maintenance, growth control, 
updating, error detection and correction, information retrieval, 
security and recovery. 
6. Documentation Function 
This function deals with the administrative activity 
of the system development process. The preparation of all the 
necessary documents that support the system development effort 
Mene main goal of this function. Documents in this activity 
range from the most insignificant one page report to the most 
sophisticated user's manual, operator's manual, or system 
design manual. 
7. Hardware/Software Evaluation Function 
The establishment of hardware and software specifica- 
mEomomimiecessary to make the implementation of the application 
Systems possible, the translation of those specifications into 
a computer system configuration, and the evaluation of the 
computer system are the main activities performed by this 
function. This activity involves the establishment of require- 
ments and evaluation of processors, memory, mass storage 
@evice, data communication equipment, operator's console, 
terminals, printer, operating system, programming language, 
and software packages. 
8. Human Engineering Functions 
Human Engineering or human factors as it is sometimes 
called, combines the scientific areas of computer technology, 
psychology, methods analysis, and industrial engineering. 


Its objective is the optimization of the man-machine interface 
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in an MIS. The activities performed within this function 
deal with the design or selection of terminal equipment, 
selection of the language most appropriate for communication 
meth the system, definition of the role of graphics for 
output display, and determination of the appropriateness of 
on-line and off-line procedures [12]. 
dn raining Function 
Training involves a set of activities necessary for 
good operation of the system. The training is normally 
e ated to the user's organization and the operations group. 
Pough training, users will know how to collect data, fill 
out inputs forms, and other manual procedures, and interpret 
muc output results, The operators will learn how to: organize 
mie input data for the computer, identity (label) files, 
Dance error situation, and carry out recovery procedures. 
10. Users Advisory Function 
Bee ciyiey is exercised by che user. = organiza- 
Hon. rhe idea is to assign qualified personnel within the 
Ber s Organization that can act as a consultant-for the 
oa processing group in matters concerning the application 
systems under development. 
1l. Planning Function 
Pe oor cion of schedules, time development estimates, 
we e aoli ment Of priorities, are Some of the typical 


activities involved in planning. 
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B. SYSTEM DEVELOPMENT TEAM PERSONNEL REQUIREMENTS 
The functions explained in the above section are accom- 
plished by personnel who must possess the skills listed below. 
1. System Analyst 
He is a data processing specialist. Some of the de- 
Enned skills of a system analyst are: at least an undergraduate 
EHeucaturonal] background, a logical mind, an ability to work 
with others, an ability to solve problems, creativity, initia- 
ease and communication ability. He must be familiar with 
design techniques, programming languages, flowcharting and 
decision tables techniques, hardware devices, software 
packages and testing techniques. 
2. Programmer 
He 1s a data processing specialist. He must be 
familiar with program design techniques, modular and struc- 
tural programming, proficient in programming languages, and 
knowledgeable in hardware and software capabilities, and 
testing techniques. 
3. Database Administrator 
The database administrator (DBA) is not necessarily 
a data processing specialist, but it is desired that he have 
technical and management backgrounds. He must be familiar 
with the database packages, languages, operating system 
characteristics related to the database, and the hardware 
requirements for supporting the database. 
4. Maintenance Engineer 
He is normally skilled in equipment diagnosis with 


knowledge of peripheral devices, transmission lines, modems, 
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terminals, memories and other related computer equipment. 
se Software Engineer 
He is a data processing specialist. He is familiar 
in detail with operating systems, languages programming, 
software maintenance and other software areas. 
6. Technical Writer 
He is not necessarily a data processing specialist; 
although, some training in this area is desired. He must be 
able to translate the technical information generated through 
the system development process into an understandable docu- 
ment. He must also be able to write all those documents 
mainly oriented toward the users, as for example the user's 
manual, in a non-technical language. 
7. Human Engineer 
The human engineer specialist must possess character- 
Eies that are very difficult to find in one person. Ideally 
a human engineer specialist should have several degrees 
ranging trom Ph.D's to Bachelor's degree in areas such as: 
experimental psychology, electronics, mathematics, computer 
technology, anthropology, physics and pedagogy, dealing with 
machine and human behavior. In order to overcome this problem 
the human engineering function is exercised by a team of 
Speeial@sts with the above backgrounds [40]. 
8. User Advisor 
He is normally a professional in the user's organiza- 
mom. Capable of assisting the data processing group in those 


areas concerning the user's application system. 
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C. STRUCTURE OF THE SYSTEM DEVELOPMENT TEAM 

In this section the structure of the system development 
meam is explained. The discussion that follows is general, 
since each organization is free to make their own adaptations 
mecoraing to their particular situation. 

The system development team for a MIS should be composed 
of two groups. One group is the system development control 
group and the other group is the project development team. 
The composition and functions of each group follows: 

io oeem Development Control Group) (sDCG) 

me oDCG is the group that ts sehareged with assuring 
eme Success of the MIS development. Basically, this group 
Meals with: interface problems between the major functions 
Ere MIS, planning activities, allocation of resources, 
we ma ational changes, and organizational conflicts. The 
composition of this group may be as follows: 
one im Director 
He should be selected by the organization; pre- 
Pemeaply an executive at the top level who will coordinate all 
mee tivities of the group. Some organizations choose for 
this position a manager from the user area. Others like to 
meswomaite a data processing specialist. Of his responsibili- 
ties the following are the most important [12]: 
- He must translate the requirements of top manage- 
ment to the MIS staff. 
- He must communicate the constraints and capabili- 


ties of technology from the MIS staff to top management. 











- He must direct the MIS development effort by 
establishing budgetary and schedule goals and must measure 
progress against goals. 

- He must be able to challenge the MIS staff's 
demands for additional resources, when they are not justified, 
and to support these demands to top management, when they are 
justified. 

Pres Director sas sis tantes 

Sanace themis director miy Dera non technical 
professional, he needs colaborators who are technical experts. 
These experts are the following: senior analyst/programmers, 
System planners, specialists from the user's area, database 
administrator, and clerical personnel. There should be as 
mew as are necessary for carrying out the required functions. 

Ane Project Development Team 

The project development team is in charge of the 
design of each subsystem that is a component of a MIS. There 
Will be as many project development teams as there are sub- 
systems under development. The project development team 
EXPLs directly to the system development team control group. 
ine approach used in the composition of this team is the one 
called the chief programmer team. This team may be composed 
of the following way [41]: 

wer Programmer Whowls inmeliargemot theyactivities 
of analysis, design, programming, testing, and documentation 


of the subsystem. 
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- A back-up programmer who must be able to substitute 
mepetie Chief programmer at any time. His main function is 
wer help in the design as a thinker, discussant and evaluator. 

AteadiMinistraton whe controls the resources allo- 
cated to the project: money, personnel, space, machines and 
materials. 

- A technical writer who is responsible for trans- 
lating all the manuscripts produced by the chief programmer 
into readable and understandable documents. 

- Two secretaries, one for the administrator and the 
Ae tor the technical writer. They handle. project corres- 


pondence and non-product files. 


=A program clerk who is responsible for maintaining 
all the technical records of the team in a programming- 
pmeeaucet library. 

- The tester, who is responsible for preparing all 
the necessary test data cases and the test plan. 

ERU Otbersstems 

In many organizations the prajeerwer fort, from the 
initial study until the maintenance and follow-up phase, is 
ner esponsibility of the project team. This includes hard- 
ware/software configuration and evaluation. This can be 
carried out by a team composed of some chief programmers and 
backup programmers. However, other organizations may have 
other teams in addition to the project development team. 
These teams perform some of the functions described at the 


beginning of this Appendix. Basically chezsemleturerof’the 
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project development team which includes other teams is the 


following: 


- Project development team previously explained. 

- Evaluation team who will perform the functions of 
configuring and selecting the computer system. 

- Testing team who will perform the activities of 
the testers in the project team approach. 

- Implementation team who will perform the functions 
of installation, operation, maintenance and follow-up. This 
team should be considered by any data processing organization 
because the demand for system maintenance can be such that 
the project team will have to devote its effort to this 
activity rather than to developing systems. 

User advisory board. Thıs 15727 9r0up of qualified 
professionals of the user's organization who will assist the 
project team in all those areas concerned with the subsystem 
under development. 

- Human engineering team which will perform the func- 
ENS that were explained in previous sections. 

The main disadvantage of creating many teams is the 
manpower requirement and the activity of control is required 
order to obtain work coordination. However, the approach 
of having several teams can speed up the development process 


er satine a partition of work in a large system, 
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APPENDIX B 


1. e TRETDATABASETAFPROACH 


During recent years data base systems have received 
greater attention from computer specialists. The terms data 
base, data bank, corporate data bank, generalized data base, 
and common data base are used synonymously to indicate the 
central repository, in a logical sense, of all automated 
data available to the organization. The concept of a data 
base system extends the definition to include the capture, 
update, storage, manipulation, and dissemination of data 
used within the organization in a controlled, consistent 
fashion. 


The general objective of a data base approach is the 


elimination or minimization of data fragmentation, data re- 
dundancy, data inconsistency, and inconsistent data manipu- 
MID which is typical of many file processing environments 


[43, 44]. 


A. PLANNING FOR THE DATABASE SYSTEM 

The commitment to a data base approach is a major organi- 
zational decision. Essential to the success of the imple- 
mentation of the data base system is the support of the user, 
management, and data processing groups. The main components 


of a database plan are the following [43, 44, 45, 46]: 
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E naton or Gals 
The data base plan should be a subset of the overall 
data processing plan. Development of the database system 
is based on a general statement of goals to be achieved within 
the data base system; as such, these goals must based on the 
organization's long range plan. These objectives must then 
be communicated to the user, management, and data processing 
groups. They must include the estimates of costs, resources, 
time required to develop a database system, and the respon- 
sibilities of users, management, and data processing. 
establishment of Data Base Administration (DBA) 
Function 
The development of a data base-supported MIS requires 
the standardization and coordination of definition, capture, 
storage, update, manipulation and dissemination of data. 
These requirements are administered and centralized in a func- 
tıom defined as the Data Base Administration function, with 
the Data Base Administrator being responsible not only for 
mae coordination and control of the data base, but also for 
the establishment of the standards and procedures for coordina- 
tiem amd comtrol, and the evaluation and selection of the 
software required. 
The Data Base Administrator and his staff comprise 
the data base development team, which is in charge of the exe- 
cution of the data base plan. 
3. Development of Data Collection Standards 
The development of data collection standards is a key 


task in the data base plan. The data collection standards 
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lead to the identification and documentation of the existing 
and projected information needs of the organization. 
4. Acquisition and Installation of the Data Dictionary/ 
Directory System 
The Data Dictionary/Directory System (DD/DS) is one 
of the most important tools for the coordination and control 
Of the data base system. The DD/DS interfaces with the data 
administrator, the system analyst, the programmer, the user, 
and the various software elements of this component of the 
data base system. The dictionary function answers the ques- 
tion, "What data is available or contained in the organiza- 
tion's data base?" The directory function replies to: "Where 
is the data stored?" 
5. Documentation of the Present and Project Data System 
This process is an extension of the data collection 
Erocedures. The Data Base Administrator records the collected 
data as it currently exists and as it is expected to be. 
6. Analysis of Documented Data 
The data documented in the preceding step is care- 
Ru analyzed for common areas ot information, as well as 
data redundancy, data inconsistency, and application inter- 


relationships. 


7. Selection of the Nucleus System 
The analysis of the documented data, performed in 
Mieeprier step, forms the basis for selecting a nucleus appli- 
clon tarea” that represents the first system development 
effort under the integrated data base system. The purposes of 
Men titying the nucleus are: 
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- Definition of the initial applications to be imple- 
mented in the data base system. 

- Establishment of requirements for selection of a 
data base software package. 

See Der mas lon Of the Logical Data Base Structure 

The Data Base Administrator describes all pieces of 
data and how each relates, according to its many uses across 
the organization. The logical design is totally independent 


of any particular data base software package. 


we Evaluation and Selection of a Data Base Software 
Package 


The Data Base Administrator establishes the perform- 
ance criteria against which the data base software package 
is measured, In addition to the proposal of the various 
data base software vendors, the Data Base Administrator should 
Take into consideration the alternative of in-house develop- 
ment. In evaluatıng and selecting the data base software, 
special attention must be placed on how it interfaces with 
the operating system, language compilers, and hardware avail- 
fore in the organization. 

Mathematical modeling, benchmarking, and simulation 
methods are normally used to evaluate data base performance. 

10. Integrate and Install the Data Base Software 

The final task of the data base planning is the 
integration, testing, and acceptance of the data base software. 
The Data Base Administrator is responsible for establishing 


the testing plan and acceptance criteria. Upon completion of 
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this task, the data base system is implemented, and the Data 
Base Administrator will coordinate the system and data base 
design functions according to the standards and procedures 


established by the Data Base Administration function. 


B. DATA BASE DEVELOPMENT AND THE SYSTEM DEVELOPMENT PROCESS 
several aspects of the traditional system development 
cycle are not affected; however, there are crucial areas that 
must be modified as an organization moves to implement a data 
base supported MIS. The modifications are the following [47]: 

ee eparatıon of the data definition and data base design 
function from the system design function. 

- Project Development Team is responsible for analysis 
of user requirements, detailed specifications, coding, docu- 
mentation, testing and implementation. 

- Project Development Team is responsible for the identi- 
fication of data requirements. 

- Project Development Team is not responsible for file 
ecto, Lt will submit a request for data to a data base 
de sen group, a group that reports directly to the DBA. 

The separation of the data base design function and sys- 
EPemedesion function is necessary in order to assure that the 
Standardization and coordination of data definition, capture, 
storage, update, manipulation and dissemination are observed; 
however, a close communication must exist between the data 
base design group and the project development team throughout 
the system development process to ensure complete understand- 


ing and agreement as to data characteristics. 
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C. DATA BASE DOCUMENTATION 

The same principles that applied to the system documen- 
tation phase can apply to the data base documentation phase. 
This important responsibility includes the recording of pro- 


cedures, standards, guidelines and data base description 


necessary for the proper, efficient and continuing utilization 
of the data base environment. Reference [48], outlines the 
following documents as some of the most important: 

- Description of Data sources, where the Data Dictionary 
is the primary initial tool for determining potential sources 
or Information. 

- Data base detailed specifications. 

- Description of the data base which includes logical and 
physical data base organization and data attributes. 

- Standards, which include the standards for data collec- 
mon, Capture, storage, manipulation and dissemination. 

- Data access and manipulation procedures. 


Passwords and user identification. 


- Back-up procedures, which include identification of 
the data to be backed-up, back-up facilities to be used, and 
back-up schedule. 

- Restart and recovery procedures. 

- Data base testing sepcifications. 


- Data base training, education procedures, and manuals. 
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